编写GC友好代码(1)

看到李建斌《JVM内存管理/GC模型/编写GC友好的代码》的ppt，将其中的实例部分摘录下来。
另外JavaOne2007上有篇《Garbage-Collection-Friendly Programming》的68页PPT，介绍得挺不错，下载地址http://img.pusuo.net/2009-08-13/110313148.pdf

•JVM喜欢生命周期短的，小的对象

•JVM创建对象的速度非常高，已经非常接近C++

•GC回收生命周期短的对象非常高效

–前面提到的新生代复制算法，对于生命周期短的对象，不需要扫描和复制就能回收

–

•使用更多生命周期短的、小的、不改变指向(immutable)的对象

•不要害怕创建临时对象作为中间计算的结果

•不要滥用对象池(Object Pool)

–出于节俭的心态，程序员总是倾向于使用对象池作为缓冲

•除非创建对象的开销较大,否则对象池不一定能提高性能，反而会影响GC效率

–比如从数据库query生成对象，pooling是有帮助的；但如果不涉及到DB/IO/Network/紧张资源的对象创建，pooling反而有反效果

–对象池生命周期长，每次full gc都要处理(mark, compact,etc)

–如果涉及多线程共享问题，对象池还可能带来同步等额外开销，得不偿失

–容易产生内存泄漏

•当使用Array-based的数据结构(ArrayList,HashMap等)时，尽量减少resize

–比如new ArrayList时，尽量估算size，在创建的时候把size确定

–减少resize可以避免没有必要的array copying,gc碎片等问题

•如果一个List只需要顺序访问，不需要随机访问（Random Access），用LinkedList代替ArrayList

–LinkedList本质是链表，不需要resize， 但只适用于顺序访问

•避免Java内存泄漏

•Java内存泄漏VS C/C++内存泄漏

–C/C++内存泄漏：把东西锁到抽屉里面，但钥匙丢了(Object unreachable)

–Java内存泄漏：把有用和没用的东西都摆满房间，清洁工（GC）分不清哪些是有用的，哪些是没用的。没用的东西没办法清理。(Object reachable but unused)

•Java内存泄漏类型

–传统型：Heap越来越大，直到OOM

–临时型：Heap临时变得很大，在某个时刻会突然变很小。导致频繁Full GC

•Java内存泄漏的经典原因

–对象定义在错误的范围(Wrong Scope)

–异常(Exception)处理不当

–集合数据管理不当

–String陷阱

对象定义在错误的范围(WrongScope)

•JVM喜欢生命周期短的对象，这样做已经足够高效