应用程序在运行中为了某种特殊需求，经常需要临时获得一些内存空间，所以作为较完善的操作系统必须具有动态分配内存的能力。对于实时操作系统在保证系统在动态分配内存时，他的执行时间必须是可确定的所以UCOS II改进动态分配函数和释放内存的函数malloc（）和free(),使他们可以对大小固定的内存块进行操作，从而使函数malloc()和free()的执行时间成为可确定的。
UCOS II对内存进行两级管理，即把一个连续的内存空间分成若干分区，每个分区又分为若干大小相等的内存块。操作系统以分区为单位来管理动态内存，而任务以内存块为单元来获得和释放动态内存。内存分区及内存块的使用情况由内存控制块来记录。


UCOS II以内存块为单元向应用程序提供动态内存。内存块的大小由用户定制。

大小相等的多个内存块可以组成一个内存分区。内存分区是系统对内存进行管理的基本单位。定义一个二维数组来确定内存分区及其内存块。INT16U IntMenBuf[10][10]来存储INT16U类型的数据，10个内存块。每个内存块长度为10的内存分区。

为了感知和有效管理内存分区，定义一个叫做内存控制块(OS_MEM）的数据结构用来记录和跟踪每个内存分区的状态。


内存控制块的内存分区指针OSMemAddr指向内存分区。素内存分区中的各个内存块又组成了一个单向链表，内存控制块的链表指OSMemFreeList就指向了这个单向链表的头。其他三个变量分别记录内存块的长度、总数目以及现在还未被分配的内存块数目。
总结：

通过定义一个二维数组在内存中划分一个内存分区，其中的所有内存块应大小相等。

系统通过与内存分区相关联的内存控制块来对内存分区进行管理。

划分及创建内存分区根据需要由应用程序负责，而系统只提供可供任务调用的相关函数。

在UCOS II中，在使用和释放动态内存的安全性方面，要由应用程序全权负责。

第七章 动态内存管理

7.1 内存控制块

    μC/OS-Ⅱ对内存进行两级管理，即把一个连续的内存空间分为若干各分区，每个分区分为若干个大小相等的内存块。操作系统以分区为单位来管理动态内存，而任务以内存块为单位来获取和释放动态内存。

7.1.1 可动态分配内存划分

1. 内存块

   μC/OS-Ⅱ以内存块为单位向应用程序提供动态内存。内存块的大小由用户定制。

2. 内存分区

   大小相等的多个内存块可以组成一个内存分区。内存分区是系统对内存进行管理的基本单位。

3. 内存分区与内存块的定义

   INT16U IntMemBuf[10][10];  有10个内存块，每个内存块长度为10的内存分区。




7.1.2 内存控制块OS_MEM的结构

    内存控制块（OS_MEM）：记录和跟踪每一个内存分区的状态。

7.1.3 空内存控制块链表

在μC/OS-Ⅱ初始化时，会调用内存控制块的初始化函数OS_MemInit()定义并初始化一个空内存控制块链表。




7.2 动态内存的管理

7.2.1 创建动态内存分区OSMemCreate()

OS_MEM * OSMemCreate(void *addr,INT32U nblks, INT32U blksize, INT8U *err);




注：分区的内存块至少有两块；每个内存块的空间至少能存放一个指针。

7.2.2 请求获得一个内存块OSMemGet()

void * OSMemGet(OS_MEM *pmem,INT8U *err);




在调用函数OSMemGet()时，应该事先知道该分区中内存块的大小，并且在使用时不能超过该内存长度。

7.2.3 释放一个内存块OSMemPut()

INT8U OSMemPut(OS_MEM *pmem, void*pblk);




在调用OSMemPut()函数的一个内存块时，一定要确保把该内存块释放到它原来所属的内存分区中。

7.2.4 查询一个内存分区的状态OSMemQuery()

    INT8UOSMemQuery(OS_MEM *pmem, OS_MEM_DATA *pdata);

分析JDK的动态代理原理
一、什么是动态代理

动态代理的意思是通过生成代理对象来达到不改变源码的情况下，对代理的接口进行了方法的增强，主要的应用有Spring的AOP、事务管理等等

二、动态代理的原理

那动态代理的原理是什么呢，我们可以分析Proxy类的源码来进一步分析动态代理的原理，

首先就是代理对象的生成，是通过的Proxy类的的静态方法newProxyInstance生成的


此方法有三个参数，分别是类加载器，要代理的接口数组，实现了InvocationHandler接口的类的实例，进一步跟踪这个方法，这个方法主要做的事有先进行了权限检查，然后通过getProxyClass0方法生成了一个Class对象,而且通过这个Class对象获取Constructor对象，再使用Consturctor对象生成代理类的一个实例，即$Proxy0的一个实例




con是一个以constructorParams为参数的构造器对象，而constructorParams参数是InvocationHandler的class对象


进一步点进getProxyClass0方法进行跟踪，可以看到此方法主要是通过以下语句来获取Class对象的，



这个方法的意思是从proxyClass缓存里获取一个Class对象，这个方法挺长的，里面做的事情是看缓存里有没有我们需要的Class对象，没有则通过一系列的操作帮我们生成一个,而这个方法里面的关键语句是以下这个

可以点进apply方法，这个方法是Proxy的静态内部类ProxyClassFactory里的方法，这个方法主要做的事情有获取代理类的类名和包名

然后根据获取到的类名、要代理的接口数组和访问标志来生成一个字节码文件，即Class文件，实际上生成的是$Proxy0.class文件


最后根据类加载器，代理类类名，字节码文件和文件的长度生成一个Class对象,defineClass0是一个本地方法，就不进一步探究了



那么说完了原理，就举个栗子来看下具体是怎样使用的，首先新建一个要被代理的类，这个类实现了一个接下来要进行代理的接口

然后如果要进行代理的话就要新建一个实现了InvocationHandler接口的类，此类实现了InvocationHandler接口的invoke方法

invoke方法的三个参数是proxy：代理类的实例，method：被代理类或接口的Method实例，args：调用方法所需要的参数

不过在invoke方法里我们并没有用到proxy参数，这个参数的作用是让我们通过反射来获取代理对象的一些信息和可以返回一个代理对象的引用

最后就是测试代理的效果

通过Proxy.newProxyInstance来生成一个代理对象，并将它转型为Interface类型并把这个对象传给了Inteface引用，因为这样我们才能去调用被代理的方法，输出如下

可以看到虽然执行的是consumer方法，实际上调用的是实现了InvocationHandler接口的类里的invoke方法，那么问题又来了，invoke方法是怎样自动被调用的呢，通过输出可以看到proxy实例的类是$Proxy0，从而得知Proxy.newProxyInstance帮我们生成的是$Proxy0类的一个实例，而通过前面的分析其实$Proxy0类是JVM根据我们所传入的代理类的类名和要代理的接口动态生成的


可以设置以下语句来生成$Proxy0.class从而分析$Proxy0类的源码



分析$Proxy0类的源码可以看到$Proxy0类是继承了Proxy类并实现了我们要进行代理的Interface接口，而构造器是调用父类的


$Proxy0类有一个dosomething方法，此方法即是被代理的方法，这个方法里调用的是父类的InvocationHandler的invoke方法，proxy为this，即本类对象的引用，m3表示的如下图，调用m3不需要参数



dosomethingelse方法的原理也差不多，不过不同的是这个方法有一个字符串参数


$Proxy0类还代理了Object类里的equals，toString和hashCode方法






分析到这里我们就知道了invoke方法是怎样自动被调用的，例如调用了dosomething方法，而调用这个方法的是$Proxy0类的实例，即调用的是$Proxy0类里的dosomething方法，dosomething方法里调用的是父类Proxy里的InvocationHandler实例的invoke方法，

所以达到了我们想要的代理的效果，我觉得这里也体现了多态性。

之前在做项目中遇到spring无法进行事务代理问题，最后发现是因为没有写接口

我们先来分析一下Spring事务管理机制的实现原理。由于Spring内置AOP默认使用动态代理模式实现，我们就先来分析一下动态代理模式的实现方 法。动态代理模式的核心就在于代码中不出现与具体应用层相关联的接口或者类引用，如上所说，这个代理类适用于任何接口的实现。下面我们来看一个例子。

public class TxHandler implements InvocationHandler {
private Object originalObject;
public Object bind(Object obj) {
　this.originalObject = obj;
　return Proxy.newProxyInstance(obj.getClass().getClassLoader(),obj.getClass().getInterfaces(),this);
}

public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
　Object result = null;
　if (!method.getName().startsWith("save")) {
　　UserTransaction tx = null;
　　try {
　　　tx = (UserTransaction) (new InitialContext().lookup("java/tx"));
　　　result = method.invoke(originalObject, args);
　　　tx.commit();
　　} catch (Exception ex) {
　　　if (null != tx) {
　　　　try {
　　　　　tx.rollback();
　　　　} catch (Exception e) {
　　　}
　　}
　}
} else {
　result = method.invoke(originalObject, args);
}
return result;
}
}

下面我们来分析一下上述代码的关键所在。

首先来看一下这段代码：

return Proxy.newProxyInstance(
　obj.getClass().getClassLoader(),obj.getClass().getInterfaces(),this);

java.lang.reflect.Proxy.newProxyInstance方法根据传入的接口类型 （obj.getClass.getInterfaces()）动态构造一个代理类实例返回，这也说明了为什么动态代理实现要求其所代理的对象一定要实现 一个接口。这个代理类实例在内存中是动态构造的，它实现了传入的接口列表中所包含的所有接口。

再来分析以下代码：

public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
　……
　result = method.invoke(originalObject, args);
　……
　return result;
}

InvocationHandler.invoke方法将在被代理类的方法被调用之前触发。通过这个方法，我们可以在被代理类方法调用的前后进行一些处 理，如代码中所示，InvocationHandler.invoke方法的参数中传递了当前被调用的方法（Method）,以及被调用方法的参数。同 时，可以通过method.invoke方法调用被代理类的原始方法实现。这样就可以在被代理类的方法调用前后写入任何想要进行的操作。

Spring的事务管理机制实现的原理，就是通过这样一个动态代理对所有需要事务管理的Bean进行加载，并根据配置在invoke方法中对当前调用的 方法名进行判定，并在method.invoke方法前后为其加上合适的事务管理代码，这样就实现了Spring式的事务管理。Spring中的AOP实 现更为复杂和灵活，不过基本原理是一致的。