编写GC友好的代码

看到了《淘宝前台系统优化实践-吞吐量优化》,也是对编写GC友好的代码感兴趣,搜索到了下文。

原文:http://nileader.blog.51cto.com/1381108/795517


上周听了淘宝网技术专家蒋江伟的一个分享《淘宝前台系统优化实践-吞吐量优化》   , 对其中“编写GC友好的代码”一节颇有兴趣,并存在疑问,回去后反复试验,从网上找资料,在蒋江伟的帮助下,算是得出了自己的结论。

      首先,根据分享内容,结合 PPT 摘录了一些基础的东西, FULL GC 就是对 old 区的一次垃圾回收 . 应用监控中比较关心的。

 那么究竟谁进入了OLD区呢? 对象进入OLD区几个途径:第一类是创建的时候直接进入, 这类对象多半是超过指定size的数据,如缓存。第二类比较常见,在minorGC触发的时候,交换分区s0/s1放不下, 向OLD区转移的对象.(就是在Young区创建, 但是生命周期足够长, 并且在s中放不下了). 
      对象创建到垃圾回收的步骤简要描述如下:

1.    对象在Eden区完成内存分配.

2.    当Eden区满了, 再创建对象, 会因为申请不到空间, 触发minorGC, 进行young(eden+1survivor)区的垃圾回收.

3.    minorGC时,Eden不能被回收的对象被放入到空的survivor(Eden肯定会被清空),另一个survivor里不能被GC回收的对象也会被放入这个survivor,始终保证一个survivor是空的.

4.    当做第3步的时候,如果发现survivor满了,则这些对象被copy到old区,或者survivor并没有满,但是有些对象已经足够Old,也被放入Old区 XX:MaxTenuringThreshold.

5.    当Old区被放满的之后,进行完整的垃圾回收(FULL gc).

      好了   ,  现在开始进行测试了   .   写了如下的测试代码   :

         准备两个测试页面:

Withnull.jsp

 
 
  1. <%@page session="false"%> 
  2. <% 
  3. int size = (int)(1024 * 1024 * 1); 
  4. byte[] buffer = new byte[size]; 
  5. out.print(buffer); 
  6. <STRONG><SPAN style="COLOR: #ff0000">buffer = null;</SPAN> 
  7.  
  8.  
  9. </STRONG> 
  10.  
  11.  
  12.  
  13. Thread.sleep(50); 
  14. out.print("With statement: buffer = null;"); 
  15. %> 

nonull.jsp

 
 
  1. <%@page session="false"%> 
  2. <% 
  3. int size = (int)(1024 * 1024 * 1); 
  4. byte[] buffer = new byte[size]; 
  5. out.print( buffer ); 
  6. Thread.sleep(50); 
  7. out.print("No statement: buffer = null;"); 
  8.  
  1. %> 
  1.  
 
 
  1. 软件版本: 
  2. Java(TM) SE Runtime Environment (build 1.6.0_10-b33)  
  3. Tomcat 6.0.20  
  4. Tomcat启动参数: -Xmx256m -Xmn15m -XX:SurvivorRatio=6 

将两个页面都放在tomcat下, 使用ab进行压测: 
第一个:   ab  -c20  -n10000  http://localhost/withnull.jsp  
第二个:   ab  -c20  -n10000  http://localhost/nonull.jsp

在执行 第一个压测的时候, 内存与GC情况如下:


在执行 第二个压测的时候, 内存与GC情况如下:


由上面的测试可以看到: 
      如果程序中显示声明了buffer = null; 那么即使线程在进行sleep的时候, GC仍然可以对那些没有引用的对象进行回收, 所以不需要进入到OLD区了. 于是FGC基本没有. 而如果没有声明的话, 那么在方法调用没有结束前, buffer一直存在, 于是源源不短的buffer对象向old转移, 导致FGC的频繁发生.

     另外我们也可以发现, 第二个测试运行一段时间之后, FGC也几乎没有了.(图中一直保持在61), 那这是为什么呢? 我的猜想是JVM进行了实时的优化, 他认为这段程序一直会被运行, 有必要进行优化了. 所以就启动了他的 JIT 优化. 
相关的资料在: http://docs.huihoo.com/javaone/2007/java-se/TS-2906.pdf 这个文档的第17页.

另外, 有几点经验是: 
这个特性不错,上次我们测试的时候也体现出来了。
1、    方法内大对象生命周期越短越好,尽量不要跨长时间的方法.
2、    将耗时的程序块独立起来, 千万不要将这样的程序快放入大对象的生命周期中.

本文出自 “ni掌柜的笔记” 博客,请务必保留此出处http://nileader.blog.51cto.com/1381108/795517

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值