标签：
先看一下JVM的内存模型：
从大的方面来讲，JVM的内存模型分为两大块：
永久区内存（ Permanent space ）和堆内存（heap space）。
栈内存（stack space）一般都不归在JVM内存模型中，因为栈内存属于线程级别。
每个线程都有个独立的栈内存空间。
Permanent space里存放加载的Class类级对象如class本身，method，field等等。
heap space主要存放对象实例和数组。
heap space由Old Generation和New Generation组成，Old Generation存放生命周期长久的实例对象，而新的对象实例一般放在New Generation。
New Generation还可以再分为Eden区(圣经中的伊甸园)、和Survivor区，新的对象实例总是首先放在Eden区，Survivor区作为Eden区和Old区的缓冲，可以向Old区转移活动的对象实例。
下图是JVM在内存空间（堆空间）中申请新对象过程的活动图（点击看大图）：
没错，我们常见的OOM（out of memory）内存溢出异常，就是堆内存空间不足以存放新对象实例时导致。
永久区内存溢出相对少见，一般是由于需要加载海量的Class数据，超过了非堆内存的容量导致。通常出现在Web应用刚刚启动时，因此Web应用推荐使用预加载机制，方便在部署时就发现并解决该问题。
栈内存也会溢出，但是更加少见。
堆内存优化：
调整JVM启动参数-Xms -Xmx -XX:newSize -XX:MaxNewSize，如调整初始堆内存和最大对内存 -Xms256M -Xmx512M。 或者调整初始New Generation的初始内存和最大内存 -XX:newSize=128M -XX:MaxNewSize=128M。
永久区内存优化：
调整PermSize参数 如 -XX:PermSize=256M -XX:MaxPermSize=512M。
栈内存优化：
调整每个线程的栈内存容量 如 -Xss2048K
最终，一个运行中的JVM所占的内存= 堆内存 + 永久区内存 + 所有线程所占的栈内存总和 。
内存多占1G左右，CPU利用率没有明显变化，但随着CMS收集抖动，最高达40%，CPU load平均高出1.0左右。
几乎0停顿，相比于之前每隔5分钟应用停顿3-4s，调优后的应用几乎没有停顿时间，每次”stop the world”由youngGC引起，最高也不过200+ms。
GC总时间开销显著减小20%多，吞吐量显著提升。
应用超过500ms的请求响应时间减少3%（一小时的观察，可能带有偶然性）
-Dfile.encoding=UTF-8 -J-server -Xms8000M -Xmx8000M -Xmn5000M -J-Xss256K -J-XX:ThreadStackSize=256 -J-XX:StackShadowPages=8 -J-verbosegc -J-XX:+PrintGCDetails -J-XX:+PrintGCTimeStamps -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelGC
-Dfile.encoding=UTF-8 -J-server -Xms10000M -Xmx10000M -Xmn5000M -XX:MaxTenuringThreshold=1 -XX:SurvivorRatio=30 -XX:TargetSurvivorRatio=50 -Xnoclassgc -Xss256K -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80 -XX:ParallelGCThreads=24 -XX:ConcGCThreads=24 -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+ExplicitGCInvokesConcurrent -XX:+UseTLAB -XX:TLABSize=64K
在开始前，我们需要一些数据，因为jvm调优没有一个标准的答案，根据实际应用不同而不同，但也不是完全没有章法可言，从一个实际的应用，我们也可以找出一些规律来，找出一些比较公用的，比如下面三条：
1、应用平均和最大暂停时间（stop the world）
2、吞吐量，真正运行时间/（GC时间+真正运行时间），而相对的GC开销为：GC时间/（GC时间+真正运行时间）；
3、URL的请求响应时间
使用-XX:+PrintFlagsFinal参数可以查看当前版本的虚拟机所能设置的所有参数，还可以看到其默认值。我使用6u26版本的java虚拟机，一共有663个参数，很多参数不必完全搞懂什么意思，而且很多优化项在JDK6版本中已经默认开启，所以我们只需要了解一些常用的即可。
在单机web server的情况下，最大堆的设置建议在物理内存的1/2到2/3之间，如果是16G的物理内存的话，最大堆的设置应该在8000M-10000M之间，Java进程消耗的总内存肯定大于最大堆设置的内存：堆内存（Xmx）+ 方法区内存（MaxPermSize）+ 栈内存（Xss,包括虚拟机栈和本地方法栈）*线程数 + NIO direct memory + socket缓存区（receive37KB，send25KB）+ JNI代码 + 虚拟机和GC本身 = java的内存。
我们经常碰到内存巨高的线上问题，留更多的内存给“意外情况”是一件好事也是一件坏事，好事是更多的内存可以给“错误”提供扩展空间，提升“容错性”，不至于马上宕机，但另一方面来说技术人员不会第一时间收到“吃swap”这个告警信息。
GC调优是JVM调优很重要的一步，当前比较成熟的GC基本上有三种选择，serial、Parallel和CMS，大型互联网应用基本上选择后两种，但Parallel的暂停时间实在太长，以-Xmx8000M -Xmn5000M为例，平均一次youngGC需要100ms-200ms，而FullGC最长需要6s，平均也要4s，虽然当前没有哪种GC策略能完全做到没有暂停时间，但太长的“stop the world”时间也让人无法忍受。
serial 和ParallelGC都是完全stop the world的GC，而CMS分为六步骤：
初始标记（stop the world）
1093.220: [GC [1 CMS-initial-mark: 4113308K(5120000K)] 4180786K(10080000K), 0.0732930 secs] [Times: user=0.07 sys=0.00, real=0.07 secs]
运行时标记（并发）
1094.275: [CMS-concurrent-mark: 0.980/0.980 secs] [Times: user=19.95 sys=0.51, real=0.98 secs]
运行时清理（并发）
1094.305: [CMS-concurrent-preclean: 0.028/0.029 secs] [Times: user=0.10 sys=0.02, real=0.03 secs]
CMS: abort preclean due to time 1099.643: [CMS-concurrent-abortable-preclean: 5.288/5.337 secs] [Times: user=12.64 sys=1.19, real=5.34 secs]
第二次标记（stop the world，这个例子remark前执行了一次youngGC）
1099.647: [GC[YG occupancy: 3308479 K (4960000 K)]1099.648: [GC 1099.649: [ParNew: 3308479K->42384K(4960000K), 0.1420310 secs] 7421787K->4180693K(10080000K), 0.1447160 secs] [Times: user=2.69 sys=0.03, real=0.15 secs]
1099.793: [Rescan (parallel) , 0.0121000 secs]1099.805: [weak refs processing, 0.0664790 secs] [1 CMS-remark: 4138308K(5120000K)] 4180693K(10080000K), 0.2254870 secs] [Times: user=3.00 sys=0.05, real=0.23 secs]
运行时清理（并发）
1104.895: [CMS-concurrent-sweep: 4.970/5.020 secs] [Times: user=12.43 sys=1.05, real=5.02 secs]
复原（并发）
1104.908: [CMS-concurrent-reset: 0.012/0.012 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
要想知道应用真正的停顿时间，可以使用PrintGCApplicationStoppedTime参数：
63043.344: [GC [PSYoungGen: 5009217K->34119K(5049600K)] 5985479K->1034614K(8121600K), 0.1721890 secs] [Times: user=2.62 sys=0.01, real=0.18 secs]
Total time for which application threads were stopped: 0.1806210 seconds
Total time for which application threads were stopped: 0.0074870 seconds
这样看来，真正应用暂停的时间要比stop the world时间还要稍长一点点。
本次调优我基本上放弃了ParallelGC而选择了CMS，CMS在old区很大的时候绝对是个利器，它不仅能大幅降低应用“stop the world”时间，而且还能增加应用的吞吐量。
CMS还有一种增量模式：iCMS，适用于单CPU模式，会将回收动作分作小块进行，但会增加回收时间，降低吞吐量，对于多CPU来说，可以不用考虑这种模式。
从PrintFlagsFinal参数可以得知CMS的UseCMSCompactAtFullCollection和CMSParallelRemarkEnabled参数在JDK6里一直都是默认为true的，所以我们不必显示设置它。从维护角度来看，在设置参数之前，我们应该首先看看这个参数是不是默认已经开启了，如果默认已经开启了我们就不必要再显示设置它。
选择了GC策略之后，年轻代和年老代的设置就很重要了，如果一味的追求响应时间，可以尽量把年轻代调大一点，youngGC的回收频率减小了，但回收时间也增大了，5000M的年轻代，平均回收时间在150+ms，3000M的年轻代平均回收时间在90+ms。
如果一味的增大年轻代，CMS前提下的年老代的威力也发挥不出来，更容易出现promotion failed，导致一次FullGC。但如果一味的调小年轻代，虽然单次回收时间减小，但回收频率会陡增，应用世界暂停时间也会增加，总体年轻代回收的时间也可能会增大，所以调整年轻代和年老代的比例就是一个找平衡的过程。
我的经验是年轻代的比例在2/8到4/8之间，具体情况要看实际应用情况而定。
我们都知道年轻代采用的是“copy”算法，有两个survivor空间，每次回收总有一个是空的，另一个存放的是前几次youngGC存留下来而且还不够提升到old资格的对象，所以有三个参数很重要：
-XX:MaxTenuringThreshold=15：对象晋升到old的年龄，parallelGC默认是15，CMS默认是4，设置的越大，对象就越难进入到old区，youngGC反复copy的时间就会增大。
-XX:SurvivorRatio=8，eden和survivor的比例，默认是8，也就是说如果eden为2400M，那么两个survivor都为300M，如果MaxTenuringThreshold设置的很小，那么survivor区的使用率就会降低，反之，survivor的使用率就会增大。
-XX:TargetSurvivorRatio=80，survivor空间的利用率，默认是50。
如果设置SurvivorRatio为65536，MaxTenuringThreshold为0就表示禁止使用survivor空间，在这种模式下，对象直接进入old区，而且我发现在这种模式下，photo的resin启动时间大大减少，以前170s在这种模式下只需要90+s，足足降低了一半，因为这个，我顿时对这种模式产生的兴趣，但CMS的压力就增大了，威力根本发挥不出来了，GC的时间没有减少反而增加，remark的时间也增大到3s，最后不得不忍痛割爱放弃了这种模式。
-XX:+CMSScavengeBeforeRemark这个参数还蛮重要的，它的意思是在执行CMS remark之前进行一次youngGC，这样能有效降低remark的时间，之前我没有加这个参数，remark时间最大能达到3s，加上这个参数之后remark时间减少到1s之内。
另外，在13机器上（参照机器），我发现survivor空间并没有像预期的那样大（eden的1/8），通过跟踪JVM的启动过程中发现，JVM在一定的条件下（可能跟parallelGC和默认SurvivorRatio有关）会动态调整survivor的大小，避免内存浪费。
1.方法区
也称"永久代” 、“非堆”， 它用于存储虚拟机加载的类信息、常量、静态变量、是各个线程共享的内存区域。默认最小值为16MB，最大值为64MB，可以通过-XX:PermSize 和 -XX:MaxPermSize 参数限制方法区的大小。
运行时常量池：是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池，用于存放编译器生成的各种符号引用，这部分内容将在类加载后放到方法区的运行时常量池中。
2.虚拟机栈
描述的是java 方法执行的内存模型：每个方法被执行的时候 都会创建一个“栈帧”用于存储局部变量表(包括参数)、操作栈、方法出口等信息。每个方法被调用到执行完的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。声明周期与线程相同，是线程私有的。
局部变量表存放了编译器可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(引用指针，并非对象本身)，其中64位长度的long和double类型的数据会占用2个局部变量的空间，其余数据类型只占1个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量是完全确定的，在运行期间栈帧不会改变局部变量表的大小空间。
3.本地方法栈
与虚拟机栈基本类似，区别在于虚拟机栈为虚拟机执行的java方法服务，而本地方法栈则是为Native方法服务。
4.堆
也叫做java 堆、GC堆是java虚拟机所管理的内存中最大的一块内存区域，也是被各个线程共享的内存区域，在JVM启动时创建。该内存区域存放了对象实例及数组(所有new的对象)。其大小通过-Xms(最小值)和-Xmx(最大值)参数设置，-Xms为JVM启动时申请的最小内存，默认为操作系统物理内存的1/64但小于1G，-Xmx为JVM可申请的最大内存，默认为物理内存的1/4但小于1G，默认当空余堆内存小于40%时，JVM会增大Heap到-Xmx指定的大小，可通过-XX:MinHeapFreeRation=来指定这个比列；当空余堆内存大于70%时，JVM会减小heap的大小到-Xms指定的大小，可通过XX:MaxHeapFreeRation=来指定这个比列，对于运行系统，为避免在运行时频繁调整Heap的大小，通常-Xms与-Xmx的值设成一样。
由于现在收集器都是采用分代收集算法，堆被划分为新生代和老年代。新生代主要存储新创建的对象和尚未进入老年代的对象。老年代存储经过多次新生代GC(Minor GC)任然存活的对象。
新生代：
程序新创建的对象都是从新生代分配内存，新生代由Eden Space和两块相同大小的Survivor Space(通常又称S0和S1或From和To)构成，可通过-Xmn参数来指定新生代的大小，也可以通过-XX:SurvivorRation来调整Eden Space及Survivor Space的大小。
老年代：
用于存放经过多次新生代GC任然存活的对象，例如缓存对象，新建的对象也有可能直接进入老年代，主要有两种情况：①.大对象，可通过启动参数设置-XX:PretenureSizeThreshold=1024(单位为字节，默认为0)来代表超过多大时就不在新生代分配，而是直接在老年代分配。②.大的数组对象，切数组中无引用外部对象。
老年代所占的内存大小为-Xmx对应的值减去-Xmn对应的值。
5.程序计数器
是最小的一块内存区域，它的作用是当前线程所执行的字节码的行号指示器，在虚拟机的模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、异常处理、线程恢复等基础功能都需要依赖计数器完成。
直接内存并不是虚拟机内存的一部分，也不是Java虚拟机规范中定义的内存区域。jdk1.4中新加入的NIO，引入了通道与缓冲区的IO方式，它可以调用Native方法直接分配堆外内存，这个堆外内存就是本机内存，不会影响到堆内存的大小。
试着从JVM的内存管理原理的角度来谈一下静态方法和静态属性的问题，不对的地方请指正。 (joezheng123.javaeye.com/blog/264695)
JVM的内存分为两部分：stack和heap ：
stack（栈）是JVM的内存指令区。stack管理很简单，push一定长度字节的数据或者指令，stack指针压栈相应的字节位移；pop一定字节长度数据或者指令，stack指针弹栈。stack的速度很快，管理很简单，并且每次操作的数据或者指令字节长度是已知的。所以Java 基本数据类型，Java 指令代码，常量都保存在stack中。
heap （堆）是JVM的内存数据区。heap 的管理很复杂，每次分配不定长的内存空间，专门用来保存对象的实例。在heap 中分配一定的内存来保存对象实例，实际上也只是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在stack中）,在heap 中分配一定的内存保存对象实例和对象的序列化比较类似。而对象实例在heap 中分配好以后，需要在stack中保存一个4字节的heap 内存地址，用来定位该对象实例在heap 中的位置，便于找到该对象实例。
由于stack的内存管理是顺序分配的，而且定长，不存在内存回收问题；而heap 则是随机分配内存，不定长度，存在内存分配和回收的问题；因此在JVM中另有一个GC进程，定期扫描heap ，它根据stack中保存的4字节对象地址扫描heap ，定位heap 中这些对象，进行一些优化（例如合并空闲内存块什么的），并且假设heap 中没有扫描到的区域都是空闲的，统统refresh（实际上是把stack中丢失了对象地址的无用对象清除了），这就是垃圾收集的过程。
我们首先要搞清楚的是什么是数据，什么是指令？然后要搞清楚对象的方法和对象的属性分别保存在哪里？
为了便于描述，我简单的统称：
1）方法本身是指令的操作码部分，保存在stack中；
2）方法内部变量作为指令的操作数部分，跟在指令的操作码之后，保存在stack中（实际上是简单类型保存在stack中，对象类型在stack中保存地址，在heap 中保存值）；
上述的指令操作码和指令操作数构成了完整的Java 指令。
3）对象实例包括其属性值作为数据，保存在数据区heap 中。
非静态的对象属性作为对象实例的一部分保存在heap 中，而对象实例必须通过stack中保存的地址指针才能访问到。因此能否访问到对象实例以及它的非静态属性值完全取决于能否获得对象实例在stack中的地址指针。
先分析一下非静态方法和静态方法的区别：
非静态方法有一个和静态方法很重大的不同：非静态方法有一个隐含的传入参数，该参数是JVM给它的，和我们怎么写代码无关，这个隐含的参数就是对象实例在stack中的地址指针。因此非静态方法（在stack中的指令代码）总是可以找到自己的专用数据（在heap 中的对象属性值）。当然非静态方法也必须获得该隐含参数，因此非静态方法在调用前，必须先new一个对象实例，获得stack中的地址指针，否则JVM将无法将隐含参数传给非静态方法。
而静态方法无此隐含参数，因此也不需要new对象，只要class文件被ClassLoader load进入JVM的stack，该静态方法即可被调用。当然此时静态方法是存取不到heap 中的对象属性的。
总结一下该过程：当一个class文件被ClassLoader load进入JVM后，方法指令保存在stack中，此时heap 区没有数据。然后程序技术器开始执行指令，如果是静态方法，直接依次执行指令代码，当然此时指令代码是不能访问heap 数据区的；如果是非静态方法，由于隐含参数没有值，会报错。因此在非静态方法执行前，要先new对象，在heap 中分配数据，并把stack中的地址指针交给非静态方法，这样程序技术器依次执行指令，而指令代码此时能够访问到heap 数据区了。
再说一下静态属性和动态属性：
前面提到对象实例以及动态属性都是保存在heap 中的，而heap 必须通过stack中的地址指针才能够被指令（类的方法）访问到。因此可以推断出：静态属性是保存在stack中的，而不同于动态属性保存在heap 中。正因为都是在stack中，而stack中指令和数据都是定长的，因此很容易算出偏移量，也因此不管什么指令（类的方法），都可以访问到类的静态属性。也正因为静态属性被保存在stack中，所以具有了全局属性。
总结一下：静态属性保存在stack指令内存区，动态属性保存在heap 数据内存区。
补充:1.在java中有一个字符常量的池， 专用来存储常量
2.基本类型是保存在栈中,例如:
int a=9; 先在栈中寻找是否有这个值,有的话将引用指向它,没有的话在上面创建这个值,接着把引用指向它
3.
栈的存取速度较快 仅次于位于cpu中的寄存器
但位于其中的数据大小和生存期必须是确定的 缺乏了灵活性 一般用于存储声明的变量
堆由于可动态分配内存 使其速度慢于栈 一般用于开辟对象空间
还由于生存期不必事先告诉编译器 事后得由gc收集
将某 class 产生出一个 instance 之后，此 class 所有的 instance field 都会新增一份，那么所有的 instance method 是否也会新增一份？答案是不会，我们用field表示字段，用method表示方法，那么加上static区分后就 有四种：
class field：有用static修饰的field
class method：有用static修饰的method
instance field：没有用static修饰的field
instance method：没有用static修饰的method
那么他们在内存中的表示为：
class field：共用一块记忆体
class method：共用一块记忆体
instance field：随着每个instance各有一块记忆体
instance method：共用一块记忆体
如果instance method也随着instance增加而增加的话，那内存消耗也太大了，为了做到共用一小段内存，Java是根据this关键字做到的，比如：instance1.instanceMethod(); instance2.instanceMethod(); 在传递给对象参数的时候，Java编译器自动先加上了一个this参数，它表示传递的是这个对象引用，虽然他们两个对象共用一个方法，但是他们的方法中所产生的数据是私有的，这是因为参数被传进来变成call stack内的entry，而各个对象都有不同call stack，所以不会混淆。其实调用每个非static方法时，Java编译器都会自动的先加上当前调用此方法对象的参数，有时候在一个方法调用另一个方法，这时可以不用在前面加上this的，因为要传递的对象参数就是当前执行这个方法的对象。
为什么静态方法中不能调用非静态方法？这是因为静态方法直接跟class相关，调用此方法的时候是类直接调用的，而不是对象，所以Java编译器就没有对象参数可以传递，这样，如果你在静态方法内部调用非静态方法，那么Java编译器怎么判断这个非静态方法是哪个对象调用的？对吧，所以Java编译器就会报错，但是也不是绝对的，Java编译器是隐式的传递对象参数，那么我们总可以显示的传递对象参数吧，如果我们把某个对象的引用传递到static方法里，然后通过这个引用就可以调用非静态方法和访问非静态数据成员了。
解析Java对象引用与JVM自动内存管理
对象引用应用程序设计接口是JDKTM1.2中新定义的。该应用程序设计接口允许应用程序以对象引用的方式与JVM的内存管理器进行交互。当应用程序需管理大量内存对象或者在新的Java对象创建之前需删除原有对象时，Java对象引用应用程序设计接口具有相当大的用途，例如：
● 基于Web的应用程序常常要求显示大量图片，当用户离开某一Web页时，往往不能确定是否能够顺利的返回。在这种程序中，应用Java对象引用API可以创建这样一个环境，即当堆内存以最小程度运行时，内存管理器创建对象。当用户返回时，应用程序就会重新载入已经创建的图片。
● 应用对象引用队列可以创建这样一个环境，当通过对象引用获得某一对象时，应用程序得到通知。然后，应用程序就可以对相关对象进行清除操作，同时使这些对象在内存管理器中合法化。
内存管理器的工作机制
下面将首先介绍未嵌入引用对象时内存管理器的工作机制，然后讨论引用对象加入之后Java堆发生的变化。
内存管理器的作用就是识别程序中不再使用的对象，并且回收其内存。
一个Java应用程序由一系列线程组成，每个线程执行一系列方法，而每个方法通过参数或局部变量来引用对象。这些引用属于引用集合中的一部分，直接进入应用程序。另外，引用集合中还包括类库中定义的静态引用变量，以及通过Java本地接口（JNI）API获得的引用。引用集合中的所有引用对象都可以被当前应用程序获取，而不必被回收。同样地，这些对象可能包含对其它对象的引用，也可以被应用程序获取，依此类推。Java堆中的其它对象视为不可获取的，而所有这些不可获取的对象在内存管理中也是合法的。如果一个不可获取的对象使用finalize()方法，任务就交给了对象所调用的收尾器（finalizer）。在内存回收期间，不具有收尾器的不可获取对象和已经调用收尾器的对象被简单回收。
内存回收的算法是不断变化的，共性的方面是从引用集合中识别可获取的对象以及回收被其它对象占据的内存空间。
加入引用对象之后的引用与常规引用的区别在于，引用对象中的引用专门由内存管理器来处理。引用对象封装了其它一些对象的引用，我们称之为指示对象。在引用对象创建的同时，也就定义了该引用对象的指示对象。
根据应用程序要求，对象可以是强引用（strong references）、次引用（soft references）、弱引用（weak references）、虚引用（phantom references）的任意组合。为了确定对象的可获取程度，JVM内存管理器从引用集合出发遍寻堆中所有到对象的路径。当到达某对象的任意路径都不含有引用对象时，则称该对象具有强获取能力；当路径中含有一个或几个引用对象时，根据内存管理器所查询的引用对象的类型分别归为次获取、弱获取、虚获取。
另外，对象引用API中还定义了引用对象队列（java.lang.ref.ReferenceQueue），这是内存管理器对引用对象进行管理的一种简单数据结构。值得注意的是，在进行引用对象定义时，要求phantom reference对象必须产生于一个引用对象队列，而soft reference和weak reference对象则无此限制，如：
ReferenceQueue queue = new ReferenceQueue();
PhantomReference pr = new PhantomReference(object, queue);
Soft References 应用实例
下面以在基于web的应用程序中使用soft references为例，来说明Java对象引用与JVM的内存管理器进行交互的原理。
当用户打开某一web页时，applet代码获得图片并且得到显示。如果在代码中同时创建了该图片对象的soft references，那么当用户离开该web页时，内存管理器对图片所分配的内存是否回收做出选择。当用户返回该web页时，在applet代码中使用SoftReference.get方法就会得到图片才内存中是否仍存在的消息。如果在内存管理器中未创建该图片，在web页上会很快得到显示；否则，applet代码就会重新获取。
下面是Example.java的完整源代码。
import java.awt.Graphics;import java.awt.Image;import java.applet.Applet;import java.lang.ref.SoftReference;public class Example extends Applet { SoftReference sr = null; public void init() { System.out.println("Initializing"); } public void paint(Graphics g) { Image im = (sr == null) ? null : (Image)(sr.get()); if (im == null) { System.out.println("Fetching image"); im = getImage(getCodeBase(),"yundong.gif"); sr = new SoftReference(im); } System.out.println("Painting"); g.drawImage(im, 25, 25, this); g.drawString("运动之美",20,20); im = null; /* Clear the strong reference to the image */ } public void start() { System.out.println("Starting"); } public void stop() { System.out.println("Stopping"); }}
在上面的代码中，对象image是一个图片对象，传递给一个SoftReference对象sr。其中image对象是sr的指示对象，sr中的引用域是从次引用（soft reference）到 image。
Weak References分析
对于一个稳定的对象，比如说线程类对象，当需要获取外部数据时，在程序中应用weak references是非常理想的。如果利用引用队列创建了某一线程的weak reference，那么当线程不再具有强获取能力时，应用程序得到通知，根据此通知，应用程序才能执行相关数据对象的清除工作。
当内存管理器未发现strong references 和 soft references 时，我们称对象具有弱获取能力，即在到达该对象的路径中至少包含一个weak reference。程序中weak references被清除一段时间后，弱获取对象被收尾器收集。由此也可以看出，soft reference和weak reference之间的区别在于，应用soft reference时，内存管理器利用算法决定是否创建弱获取对象，而应用weak reference时，内存管理器必须创建次获取对象。
引用对象链
当到达某一对象的路径中含有多个引用对象时，就构成了引用对象链。内存管理器按照由强到弱的顺序处理引用对象，具体处理步骤包括：Soft references、 Weak references、Finalization、Phantom references和创建对象五个部分。
当内存管理器未发现前三种对象引用时，我们称对象具有虚获取能力，即在到达该对象的路径中至少包含一个phantom reference。虚引用对象直接被收尾器收集，而不被重新创建。当内存管理器发现只有phantom references时，对象就将处于等候phantom reference状态，应用程序向引用队列发出通知，然后对虚引用对象调用clear()方法，将其引用域设置为null，最后对不可获取对象执行收集清除处理任务。
通常，对象所具有的获取能力与引用对象集合直接路径中的最弱连接者相同。据此可以看出：
虚引用对象具有强获取能力，其它对象均具虚获取能力；
（b）中虚引用对象和弱引用对象均具强获取能力，故次引用对象和对象集合具有若获取能力；
（c）中虚引用对象、弱引用对象和次引用对象均具强获取能力，那么对象集合则具次获取能力。
● 在程序中使用引用对象API不但可以在一定程度上控制内存管理器，实现内存自动管理，还可以提高程序的稳定性和安全性。
● 引用对象链中各个对象的获取能力与整个链相关。
标签：
原文地址：http://my.oschina.net/liting/blog/475094
