参考两个PPT
原文： 沐剑
Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题。以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧！甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决。
这话其实也没有太大问题，的确，大部分场景下关心内存、GC的问题，显得有点“杞人忧天”了，高老爷说过：
过早优化是万恶之源。
但另一方面，什么才是“过早优化”？
If we could do things right for the first time, why not?
事实上JVM的内存模型(
)理应是Java程序员的基础知识，处理过几次JVM线上内存问题之后就会很明显感受到，很多系统问题，都是内存问题。
对JVM内存结构感兴趣的同学可以看下
这篇文章，本文就不再赘述了，本文也并不关注具体的GC算法，相关的文章汗牛充栋，随时可查。
另外，不要指望GC优化的这些技巧，可以对应用性能有成倍的提高，特别是对I/O密集型的应用，或是实际落在YoungGC上的优化，可能效果只是帮你减少那么一点YoungGC的频率。
但我认为，优秀程序员的价值，不在于其所掌握的几招屠龙之术，而是在细节中见真著，就像前面说的，如果我们可以一次把事情做对，并且做好，在允许的范围内尽可能追求卓越，为什么不去做呢？
一、GC分代的基本假设
大部分GC算法，都将堆内存做分代(Generation)处理，但是为什么要分代呢，又为什么不叫内存分区、分段，而要用面向时间、年龄的“代”来表示不同的内存区域？
GC分代的基本假设是：
绝大部分对象的生命周期都非常短暂，存活时间短。
而这些短命的对象，恰恰是GC算法需要首先关注的。所以在大部分的GC中，YoungGC（也称作MinorGC）占了绝大部分，对于负载不高的应用，可能跑了数个月都不会发生FullGC。
基于这个前提，在编码过程中，我们应该尽可能地缩短对象的生命周期。在过去，分配对象是一个比较重的操作，所以有些程序员会尽可能地减少new对象的次数，尝试减小堆的分配开销，减少内存碎片。
但是，短命对象的创建在JVM中比我们想象的性能更好，所以，不要吝啬new关键字，大胆地去new吧。
当然前提是不做无谓的创建，对象创建的速率越高，那么GC也会越快被触发。
分配小对象的开销分享小，不要吝啬去创建。
GC最喜欢这种小而短命的对象。
让对象的生命周期尽可能短，例如在方法体内创建，使其能尽快地在YoungGC中被回收，不会晋升(romote)到年老代(Old Generation)。
二、对象分配的优化
基于大部分对象都是小而短命，并且不存在多线程的数据竞争。这些小对象的分配，会优先在线程私有的 TLAB 中分配，TLAB中创建的对象，不存在锁甚至是CAS的开销。
TLAB占用的空间在Eden Generation。
当对象比较大，TLAB的空间不足以放下，而JVM又认为当前线程占用的TLAB剩余空间还足够时，就会直接在Eden Generation上分配，此时是存在并发竞争的，所以会有CAS的开销，但也还好。
当对象大到Eden Generation放不下时，JVM只能尝试去Old Generation分配，这种情况需要尽可能避免，因为一旦在Old Generation分配，这个对象就只能被Old Generation的GC或是FullGC回收了。
三、不可变对象的好处
GC算法在扫描存活对象时通常需要从ROOT节点开始，扫描所有存活对象的引用，构建出对象图。
不可变对象对GC的优化，主要体现在Old Generation中。
可以想象一下，如果存在Old Generation的对象引用了Young Generation的对象，那么在每次YoungGC的过程中，就必须考虑到这种情况。
Hotspot JVM为了提高YoungGC的性能，避免每次YoungGC都扫描Old Generation中的对象引用，采用了 卡表(Card Table) 的方式。
简单来说，当Old Generation中的对象发生对Young Generation中的对象产生新的引用关系或释放引用时，都会在卡表中响应的标记上标记为脏(dirty)，而YoungGC时，只需要扫描这些dirty的项就可以了。
可变对象对其它对象的引用关系可能会频繁变化，并且有可能在运行过程中持有越来越多的引用，特别是容器。这些都会导致对应的卡表项被频繁标记为dirty。
而不可变对象的引用关系非常稳定，在扫描卡表时就不会扫到它们对应的项了。
注意，这里的不可变对象，不是指仅仅自身引用不可变的
final对象，而是真正的Immutable Objects。
四、引用置为null的传说
早期的很多Java资料中都会提到在方法体中将一个变量置为null能够优化GC的性能，类似下面的代码：
List&String& list = new ArrayList&String&();
// some code
list = // help GC
事实上这种做法对GC的帮助微乎其微，有时候反而会导致代码混乱。
我记得几年前撒迦在HLL VM小组中详细论述过这个问题，原帖我没找到，结论基本就是：
在一个非常大的方法体内，对一个较大的对象，将其引用置为null，某种程度上可以帮助GC。
大部分情况下，这种行为都没有任何好处。
所以，还是早点放弃这种“优化”方式吧。
GC比我们想象的更聪明。
五、手动档的GC
在很多Java资料上都有下面两个奇技淫巧：
Thread.yield()让出CPU资源给其它线程。
System.gc()触发GC。
事实上JVM从不保证这两件事，而
System.gc()在JVM启动参数中如果允许显式GC，则会触发FullGC，对于响应敏感的应用来说，几乎等同于自杀。
So，让我们牢记两点：
Thread.yield()。
System.gc()。除非你真的需要回收Native Memory。
第二点有个Native Memory的例外，如果你在以下场景：
使用了NIO或者NIO框架（Mina/Netty）
使用了DirectByteBuffer分配字节缓冲区
使用了MappedByteBuffer做内存映射
由于Native Memory只能通过FullGC（或是CMS GC）回收，所以除非你非常清楚这时真的有必要，否则不要轻易调用
System.gc()，且行且珍惜。
另外为了防止某些框架中的
System.gc调用（例如NIO框架、Java RMI），建议在启动参数中加上
-XX:+DisableExplicitGC来禁用显式GC。
这个参数有个巨大的坑，如果你禁用了
System.gc()，那么上面的3种场景下的内存就无法回收，可能造成OOM，如果你使用了CMS GC，那么可以用这个参数替代：
-XX:+ExplicitGCInvokesConcurrent。
System.gc()，可以参考毕玄的几篇文章：
六、指定容器初始化大小
Java容器的一个特点就是可以动态扩展，所以通常我们都不会去考虑初始大小的设置，不够了反正会自动扩容呗。
但是扩容不意味着没有代价，甚至是很高的代价。
例如一些基于数组的数据结构，例如
StringBuilder、
StringBuffer、
ArrayList、
HashMap等等，在扩容的时候都需要做ArrayCopy，对于不断增长的结构来说，经过若干次扩容，会存在大量无用的老数组，而回收这些数组的压力，全都会加在GC身上。
这些容器的构造函数中通常都有一个可以指定大小的参数，如果对于某些大小可以预估的容器，建议加上这个参数。
可是因为容器的扩容并不是等到容器满了才扩容，而是有一定的比例，例如
HashMap的扩容阈值和负载因子(loadFactor)相关。
Google Guava框架对于容器的初始容量提供了非常便捷的工具方法，例如：
Lists.newArrayListWithCapacity(initialArraySize);
Lists.newArrayListWithExpectedSize(estimatedSize);
Sets.newHashSetWithExpectedSize(expectedSize);
Maps.newHashMapWithExpectedSize(expectedSize);
这样我们只要传入预估的大小即可，容量的计算就交给Guava来做吧。
如果采用默认无参构造函数，创建一个ArrayList，不断增加元素直到OOM，那么在此过程中会导致：
多次数组扩容，重新分配更大空间的数组
多次数组拷贝
七、对象池
为了减少对象分配开销，提高性能，可能有人会采取对象池的方式来缓存对象集合，作为复用的手段。
但是对象池中的对象由于在运行期长期存活，大部分会晋升到Old Generation，因此无法通过YoungGC回收。
并且通常……没有什么效果。
对于对象本身：
如果对象很小，那么分配的开销本来就小，对象池只会增加代码复杂度。
如果对象比较大，那么晋升到Old Generation后，对GC的压力就更大了。
从线程安全的角度考虑，通常池都是会被并发访问的，那么你就需要处理好同步的问题，这又是一个大坑，并且同步带来的开销，未必比你重新创建一个对象小。
对于对象池，唯一合适的场景就是当池中的每个对象的创建开销很大时，缓存复用才有意义，例如每次new都会创建一个连接，或是依赖一次RPC。
数据库连接池
即使你真的需要实现一个对象池，也请使用成熟的开源框架，例如Apache Commons Pool。
另外，使用JDK的
ThreadPoolExecutor作为线程池，不要重复造轮子，除非当你看过AQS的源码后认为你可以写得比Doug Lea更好。
八、对象作用域
尽可能缩小对象的作用域，即生命周期。
如果可以在方法内声明的局部变量，就不要声明为实例变量。
除非你的对象是单例的或不变的，否则尽可能少地声明static变量。
九、各类引用
java.lang.ref.Reference有几个子类，用于处理和GC相关的引用。JVM的引用类型简单来说有几种：
Strong Reference，最常见的引用
Weak Reference，当没有指向它的强引用时会被GC回收
Soft Reference，只当临近OOM时才会被GC回收
Phantom Reference，主要用于识别对象被GC的时机，通常用于做一些清理工作
当你需要实现一个缓存时，可以考虑优先使用
WeakHashMap，而不是
HashMap，当然，更好的选择是使用框架，例如Guava Cache。
最后，再次提醒，以上的这些未必可以对代码有多少性能上的提升，但是熟悉这些方法，是为了帮助我们写出更卓越的代码，和GC更好地合作。
相关 [内存 java 代码] 推荐：
- 非技术 - ITeye博客
Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题. 以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧. 甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决.
- ImportNew
文本来自StackOverflow问答网站的一个热门讨论：如何用Java编写一段会发生内存泄露的代码. Q：刚才我参加了面试，面试官问我如何写出会发生内存泄露的Java代码. 这个问题我一点思路都没有，好囧. A1：通过以下步骤可以很容易产生内存泄露（程序代码不能访问到某些对象，但是它们仍然保存在内存中）:.
- ITeye博客
堆(Heap)又被称为：优先队列(Priority Queue)，是计算机科学中一类特殊的数据结构的统称. 堆通常是一个可以被看做一棵树的数组对象. 在队列中，调度程序反复提取队列中第一个作业并运行，因而实际情况中某些时间较短的任务将等待很长时间才能结束，或者某些不短小，但具有重要性的作业，同样应当具有优先权.
- Java - 编程语言 - ITeye博客
（问题一：什么叫垃圾回收机制. ） 垃圾回收是一种动态存储管理技术，它自动地释放不再被程序引用的对象，按照特定的垃圾收集算法来实现资源自动回收的功能. 当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用，以免造成内存泄露. （问题二：java的垃圾回收有什么特点. ） JAVA语言不允许程序员直接控制内存空间的使用.
- 编程语言 - ITeye博客
不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址. Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的. GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题.
- ImportNew
2016年3月修改，结合自己的工作和平时学习的体验重新谈一下为什么要进行代码优化. 在修改之前，我的说法是这样的：. 就像鲸鱼吃虾米一样，也许吃一个两个虾米对于鲸鱼来说作用不大，但是吃的虾米多了，鲸鱼自然饱了. 代码优化一样，也许一个两个的优化，对于提升代码的运行效率意义不大，但是只要处处都能注意代码优化，总体来说对于提升代码的运行效率就很有用了.
- ITeye博客
JAVA的垃圾回收机制，让许多程序员觉得内存管理不是很重要，但是内存内存泄露的事情恰恰这样的疏忽而发生，特别是对于Android开发，内存管理更为重要，养成良好的习惯，有利于避免内存的泄漏..
这里可以把许多对象和引用看成是有向图，顶点可以是对象也可以是引用，引用关系就是有向边.
- ITeye博客
昨天中午，发了一篇
equals和==区别的博文，晚上再看时有几位大牛指出了其中的一些错误，很感谢他们的留言，一句简简单单的留言给了我对这些错误知识点改正的机会. 或许这就是从事互联网行业所提倡的互帮互助的精神吧，因为有分享，有交流，互联网才会发展的如此迅猛. 大牛提的一个观点很好，好的东西可以拿出来分享，错的东西却可能带给别人错误的理解，这一点我确实得向看了我写了一些bug博客的人道个歉.
- 码蜂笔记
JMM，Java Memory Model，Java 内存模型. 什么是内存模型，要他何用. 假定一个线程为变量var赋值：
var = 3;，内存模型要回答的问题是：在什么条件下，读取变量var的线程可以看到
3这个值. 如果缺少了同步，线程可能无法看到其他线程操作的结果. 导致这种情况的原因可以有：编译器生成指令的次序可以不同于源代码的“显然”版本，编译器还会把变量存储在寄存器而不是内存中；处理器可以乱序或并行执行指令；缓存会改变写入提交到主存得到变量的次序；存储在处理器本地缓存中的变量对其他处理器不可见 等等.
- ImportNew
你可以在网上找到一大堆资料让你了解JMM是什么东西，但大多在你看完后仍然会有很多疑问. happen-before是怎么工作的呢. 用volatile会导致缓存的丢弃吗. 为什么我们从一开始就需要内存模型. 通过这篇文章，读者可以学习到足以回答以上所有问题的知识. 它包含两大部分：第一部分是硬件层次的大体架构，第二部分是深入OpenJdk源代码和实现.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
面向 GC 的 Java
关键字：Java
　　Java程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题。以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧!甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决。
　　这话其实也没有太大问题，的确，大部分场景下关心内存、GC的问题，显得有点“杞人忧天”了，高老爷说过：
　　过早优化是万恶之源。
　　但另一方面，什么才是“过早优化”？
　　If we could do things right for the first time, why not?
　　事实上JVM的内存模型( JMM )理应是Java程序员的基础知识，处理过几次JVM线上内存问题之后就会很明显感受到，很多系统问题，都是内存问题。
　　对JVM内存结构感兴趣的同学可以看下 浅析Java虚拟机结构与机制 这篇文章，本文就不再赘述了，本文也并不关注具体的GC算法，相关的文章汗牛充栋，随时可查。
　　另外，不要指望GC优化的这些技巧，可以对应用性能有成倍的提高，特别是对I/O密集型的应用，或是实际落在YoungGC上的优化，可能效果只是帮你减少那么一点YoungGC的频率。
　　但我认为，优秀程序员的价值，不在于其所掌握的几招屠龙之术，而是在细节中见真著，就像前面说的，如果我们可以一次把事情做对，并且做好，在允许的范围内尽可能追求卓越，为什么不去做呢？
　　一、GC分代的基本假设
　　大部分GC算法，都将堆内存做分代(Generation)处理，但是为什么要分代呢，又为什么不叫内存分区、分段，而要用面向时间、年龄的“代”来表示不同的内存区域？
　　GC分代的基本假设是：
　　绝大部分对象的生命周期都非常短暂，存活时间短。
　　而这些短命的对象，恰恰是GC算法需要首先关注的。所以在大部分的GC中，YoungGC(也称作MinorGC)占了绝大部分，对于负载不高的应用，可能跑了数个月都不会发生FullGC。
　　基于这个前提，在编码过程中，我们应该尽可能地缩短对象的生命周期。在过去，分配对象是一个比较重的操作，所以有些程序员会尽可能地减少new对象的次数，尝试减小堆的分配开销，减少内存碎片。
　　但是，短命对象的创建在JVM中比我们想象的性能更好，所以，不要吝啬new关键字，大胆地去new吧。
　　当然前提是不做无谓的创建，对象创建的速率越高，那么GC也会越快被触发。
　　结论：
　　分配小对象的开销分享小，不要吝啬去创建。
　　GC最喜欢这种小而短命的对象。
　　让对象的生命周期尽可能短，例如在方法体内创建，使其能尽快地在YoungGC中被回收，不会晋升(romote)到年老代(Old Generation)。
　　二、对象分配的优化
　　基于大部分对象都是小而短命，并且不存在多线程的数据竞争。这些小对象的分配，会优先在线程私有的 TLAB 中分配，TLAB中创建的对象，不存在锁甚至是CAS的开销。
　　TLAB占用的空间在Eden Generation。
　　当对象比较大，TLAB的空间不足以放下，而JVM又认为当前线程占用的TLAB剩余空间还足够时，就会直接在Eden Generation上分配，此时是存在并发竞争的，所以会有CAS的开销，但也还好。
　　当对象大到Eden Generation放不下时，JVM只能尝试去Old Generation分配，这种情况需要尽可能避免，因为一旦在Old Generation分配，这个对象就只能被Old Generation的GC或是FullGC回收了。
　　三、不可变对象的好处
　　GC算法在扫描存活对象时通常需要从ROOT节点开始，扫描所有存活对象的引用，构建出对象图。
　　不可变对象对GC的优化，主要体现在Old Generation中。
　　可以想象一下，如果存在Old Generation的对象引用了Young Generation的对象，那么在每次YoungGC的过程中，就必须考虑到这种情况。
　　Hotspot JVM为了提高YoungGC的性能，避免每次YoungGC都扫描Old Generation中的对象引用，采用了 卡表(Card Table) 的方式。
　　简单来说，当Old Generation中的对象发生对Young Generation中的对象产生新的引用关系或释放引用时，都会在卡表中响应的标记上标记为脏(dirty)，而YoungGC时，只需要扫描这些dirty的项就可以了。
　　可变对象对其它对象的引用关系可能会频繁变化，并且有可能在运行过程中持有越来越多的引用，特别是容器。这些都会导致对应的卡表项被频繁标记为dirty。
　　而不可变对象的引用关系非常稳定，在扫描卡表时就不会扫到它们对应的项了。
　　注意，这里的不可变对象，不是指仅仅自身引用不可变的final对象，而是真正的Immutable Objects。
　　四、引用置为null的传说
　　早期的很多Java资料中都会提到在方法体中将一个变量置为null能够优化GC的性能，类似下面的代码：
　　List = new ArrayList(); // some code list = // help GC
　　事实上这种做法对GC的帮助微乎其微，有时候反而会导致代码混乱。
　　我记得几年前 @rednaxelafx 在HLL VM小组中详细论述过这个问题，原帖我没找到，结论基本就是：
　　在一个非常大的方法体内，对一个较大的对象，将其引用置为null，某种程度上可以帮助GC。
　　大部分情况下，这种行为都没有任何好处。
　　所以，还是早点放弃这种“优化”方式吧。
　　GC比我们想象的更聪明。
　　五、手动档的GC
　　在很多Java资料上都有下面两个奇技淫巧：
　　通过Thread.yield()让出CPU资源给其它线程。
　　通过System.gc()触发GC。
　　事实上JVM从不保证这两件事，而System.gc()在JVM启动参数中如果允许显式GC，则会触发FullGC，对于响应敏感的应用来说，几乎等同于自杀。
　　So，让我们牢记两点：
　　Never use Thread.yield()。
　　Never use System.gc()。除非你真的需要回收Native Memory。
　　第二点有个Native Memory的例外，如果你在以下场景：
　　? 使用了NIO或者NIO框架(Mina/Netty)
　　? 使用了DirectByteBuffer分配字节缓冲区
　　? 使用了MappedByteBuffer做内存映射
　　由于Native Memory只能通过FullGC(或是 GC)回收，所以除非你非常清楚这时真的有必要，否则不要轻易调用System.gc()，且行且珍惜。
　　另外为了防止某些框架中的System.gc调用(例如NIO框架、Java RMI)，建议在启动参数中加上-XX:+DisableExplicitGC来禁用显式GC。
　　这个参数有个巨大的坑，如果你禁用了System.gc()，那么上面的3种场景下的内存就无法回收，可能造成OOM，如果你使用了CMS GC，那么可以用这个参数替代：-XX:+ExplicitGCInvokesConcurrent。
　　关于System.gc()，可以参考 @bluedavy 的几篇文章：
　　? CMS GC会不会回收Direct ByteBuffer的内存
　　? 说说在Java启动参数上我犯的错
　　? java.lang.OutOfMemoryError:Map failed
　　六、指定容器初始化大小
　　Java容器的一个特点就是可以动态扩展，所以通常我们都不会去考虑初始大小的设置，不够了反正会自动扩容呗。
　　但是扩容不意味着没有代价，甚至是很高的代价。
　　例如一些基于数组的数据结构，例如StringBuilder、StringBuffer、ArrayList、HashMap等等，在扩容的时候都需要做ArrayCopy，对于不断增长的结构来说，经过若干次扩容，会存在大量无用的老数组，而回收这些数组的压力，全都会加在GC身上。
　　这些容器的构造函数中通常都有一个可以指定大小的参数，如果对于某些大小可以预估的容器，建议加上这个参数。
　　可是因为容器的扩容并不是等到容器满了才扩容，而是有一定的比例，例如HashMap的扩容阈值和负载因子(loadFactor)相关。
　　 Guava框架对于容器的初始容量提供了非常便捷的工具方法，例如：
　　Lists.newArrayListWithCapacity(initialArraySize); Lists.newArrayListWithExpectedSize(estimatedSize); Sets.newHashSetWithExpectedSize(expectedSize); Maps.newHashMapWithExpectedSize(expectedSize);
　　这样我们只要传入预估的大小即可，容量的计算就交给Guava来做吧。
　　反例：
　　如果采用默认无参构造函数，创建一个ArrayList，不断增加元素直到OOM，那么在此过程中会导致：
　　多次数组扩容，重新分配更大空间的数组
　　多次数组拷贝
　　内存碎片
　　七、对象池
　　为了减少对象分配开销，提高性能，可能有人会采取对象池的方式来缓存对象集合，作为复用的手段。
　　但是对象池中的对象由于在运行期长期存活，大部分会晋升到Old Generation，因此无法通过YoungGC回收。
　　并且通常……没有什么效果。
　　对于对象本身：
　　如果对象很小，那么分配的开销本来就小，对象池只会增加代码复杂度。
　　如果对象比较大，那么晋升到Old Generation后，对GC的压力就更大了。
　　从线程安全的角度考虑，通常池都是会被并发访问的，那么你就需要处理好同步的问题，这又是一个大坑，并且同步带来的开销，未必比你重新创建一个对象小。
　　对于对象池，唯一合适的场景就是当池中的每个对象的创建开销很大时，缓存复用才有意义，例如每次new都会创建一个连接，或是依赖一次RPC。
　　比如说：
　　? 线程池
　　?连接池
　　? TCP连接池
　　即使你真的需要实现一个对象池，也请使用成熟的开源框架，例如Apache Commons Pool。
　　另外，使用JDK的ThreadPoolExecutor作为线程池，不要重复造轮子，除非当你看过AQS的源码后认为你可以写得比Doug Lea更好。
　　八、对象作用域
　　尽可能缩小对象的作用域，即生命周期。
　　如果可以在方法内声明的局部变量，就不要声明为实例变量。
　　除非你的对象是单例的或不变的，否则尽可能少地声明static变量。
　　九、各类引用
　　java.lang.ref.Reference有几个子类，用于处理和GC相关的引用。JVM的引用类型简单来说有几种：
　　? Strong Reference，最常见的引用
　　? Weak Reference，当没有指向它的强引用时会被GC回收
　　? Soft Reference，只当临近OOM时才会被GC回收
　　? Phantom Reference，主要用于识别对象被GC的时机，通常用于做一些清理工作
　　当你需要实现一个缓存时，可以考虑优先使用WeakHashMap，而不是HashMap，当然，更好的选择是使用框架，例如Guava Cache。
　　最后，再次提醒，以上的这些未必可以对代码有多少性能上的提升，但是熟悉这些方法，是为了帮助我们写出更卓越的代码，和GC更好地合作。
[ 责任编辑：jj ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte}