JVM学习之垃圾回收(GC:garbage collection)

本文对比了Sun Hotspot、Oracle JRockit和IBM JVM的垃圾回收机制。每个JVM在垃圾收集、堆策略、老年代GC、碎片处理和线程本地分配等方面都有所不同。了解这些差异对于优化性能至关重要。Hotspot使用分代堆,JRockit支持连续堆和更复杂的CMS策略,而IBM JVM则在大型和小型对象分配上有独特之处。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  看完《How Garbage Collection differs in the three big JVMs》,顺便做点笔记吧,不然白看了,如有纰漏,还望指正哈。


 

原文如下:笔记就在原文上做,嘿嘿~~~~

 

 

Most articles about Garbage Collection ignore the fact that the Sun Hotspot JVM is not the only game in town. In fact whenever you have to work with either IBM WebSphere or Oracle WebLogic you will run on a different runtime. While the concept of Garbage Collection is the same, the implementation is not and neither are the default settings or how to tune it. This often leads to unexpected problems when running the first load tests or in the worst case when going live. So let’s look at the different JVMs, what makes them unique and how to ensure that Garbage Collection is running smooth.

The Garbage Collection ergonomics of the Sun Hotspot JVM

Everybody believes to know how Garbage Collection works in the Sun Hotspot JVM, but lets take a closer look for the purpose of reference.

The memory model of the Sun Hotspot JVM

The memory model of the Sun Hotspot JVM

The Generational Heap

The Hotspot JVM is always using a Generational Heap. Objects are first allocated in the young generation, specifically in the Eden area. Whenever the Eden space is full a young generation garbage collection is triggered. This will copy the few remaining live objects into the emptysurvivor space. In addition objects that have been copied to Survivor in the previous garbage collection will be checked and the live ones will be copied as well. The result is that objects only exist in one survivor, while eden and the other survivor is empty. This form of Garbage Collection is called copy collection. It is fast as long as nearly all objects have died. In addition allocation is always fast because no fragmentation occurs. Objects that survive a couple of garbage collections are considered old and are promoted into the Tenured/Old space.

Tenured Generation GCs

The Mark and Sweep algorithms used in the Tenured space are different because they do not copy objects. As we have seen in one of my previous posts garbage collection takes longer the more objects are alive. Consequently GC runs in tenured are nearly always expensive which is why we want to avoid them. In order to avoid GCs we need to ensure that objects are only copied from Young to Old when they are permanent and in addition ensure that the tenured does not run full. Therefore generation sizing is the single most important optimization for the GC in the Hotspot JVM. If we cannot prevent objects from being copied to Tenured space once in a while we can use the Concurrent Mark and Sweep algorithm which collects objects concurrent to the application.

 


总结:

1.GC运行在tenured space中的代价比较昂贵,应该尽力避免

2.为了避免GC的运行可以:a)确保从Young代复制到Old代的对象是永久的(permanent);b)tenured space不要太满。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值