为什么age=3的对象，比age=2的对象少呢？
 |
neptune
2013-04-27
2013-04-27T10:57:17.685+0800: 57590.721: [GC 57590.722: [ParNew
Desired survivor size 751619272 bytes, new threshold 3 (max 3) - age 1: 7154464 bytes, 7154464 total - age 2: 5705400 bytes, 12859864 total - age 3: 3511792 bytes, 16371656 total : 1068348K->23370K(2097152K), 0.0478420 secs] 1952947K->911586K(7340032K), 0.0482100 secs] [Times: user=0.24 sys=0.02, real=0.05 secs] YGC的间隔在3分钟，完全有时间把新生代清理好，一些线程正在引用的对象进入到survivor区形成age=1的对象（包括线程引用的一次性不能被回收的对象和一些产生的Cache对象）。再一次YGC后上次那些线程引用的一次性对象，应该被清理干净了，留下的是Cache对象，也就是说age=2的对象都应该是系统长期引用的对象（基本是不能被回收的）。那为什么在age=3时对象数变少了呢，第3次YGC回收了age=2中的那些对象？ |
 |
xiaoyu
2013-04-27
neptune 写道 2013-04-27T10:57:17.685+0800: 57590.721: [GC 57590.722: [ParNew
Desired survivor size 751619272 bytes, new threshold 3 (max 3) - age 1: 7154464 bytes, 7154464 total - age 2: 5705400 bytes, 12859864 total - age 3: 3511792 bytes, 16371656 total : 1068348K->23370K(2097152K), 0.0478420 secs] 1952947K->911586K(7340032K), 0.0482100 secs] [Times: user=0.24 sys=0.02, real=0.05 secs] YGC的间隔在3分钟，完全有时间把新生代清理好，一些线程正在引用的对象进入到survivor区形成age=1的对象（包括线程引用的一次性不能被回收的对象和一些产生的Cache对象）。再一次YGC后上次那些线程引用的一次性对象，应该被清理干净了，留下的是Cache对象，也就是说age=2的对象都应该是系统长期引用的对象（基本是不能被回收的）。那为什么在age=3时对象数变少了呢，第3次YGC回收了age=2中的那些对象？ 是的 |
 |
RednaxelaFX
2013-04-28
YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
|
|
xiaoyu
2013-04-28
RednaxelaFX 写道 YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
啊 难道没有第三次ygc ，回收age＝2的？ |
|
RednaxelaFX
2013-04-28
xiaoyu 写道 RednaxelaFX 写道 YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
啊 难道没有第三次ygc ，回收age＝2的？ 第三次YGC还活着的没晋升的上一次YGC时age=2的对象现在就变成age=3了啊。没啥问题。 如果是提早晋升了就会看到age=3的总比age=2的少，那就是问题了。 |
|
xiaoyu
2013-04-28
RednaxelaFX 写道 xiaoyu 写道 RednaxelaFX 写道 YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
啊 难道没有第三次ygc ，回收age＝2的？ 第三次YGC还活着的没晋升的上一次YGC时age=2的对象现在就变成age=3了啊。没啥问题。 如果是提早晋升了就会看到age=3的总比age=2的少，那就是问题了。 了解，其实这个看看gc 日志，老生代是否有增加就应该很明显了（就知道是否有溢出了） |
|
neptune
2013-04-28
xiaoyu 写道 RednaxelaFX 写道 xiaoyu 写道 RednaxelaFX 写道 YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
啊 难道没有第三次ygc ，回收age＝2的？ 第三次YGC还活着的没晋升的上一次YGC时age=2的对象现在就变成age=3了啊。没啥问题。 如果是提早晋升了就会看到age=3的总比age=2的少，那就是问题了。 了解，其实这个看看gc 日志，老生代是否有增加就应该很明显了（就知道是否有溢出了） 你指的溢出是什么溢出呀，是survivor溢出吗，这个基本不可能，我的Desired survivor size 751619272 bytes(716m). Desired survivor size 751619272 bytes, new threshold 3 (max 3) - age 1: 7154464 bytes, 7154464 total - age 2: 5705400 bytes, 12859864 total - age 3: 3511792 bytes, 16371656 total 不可能是溢出情况。 |
|
xiaoyu
2013-04-28
neptune 写道 xiaoyu 写道 RednaxelaFX 写道 xiaoyu 写道 RednaxelaFX 写道 YGC统计出来对象的数量不随着年龄而递增的话多半意味着有过早晋升（premature tenuring）的状况。JavaOne 2010上Tony Printezis做的"Step by Step: GC Tuning in the HotSpot Java Virtual Machine" (S314348) 里有不错的讲解。
啊 难道没有第三次ygc ，回收age＝2的？ 第三次YGC还活着的没晋升的上一次YGC时age=2的对象现在就变成age=3了啊。没啥问题。 如果是提早晋升了就会看到age=3的总比age=2的少，那就是问题了。 了解，其实这个看看gc 日志，老生代是否有增加就应该很明显了（就知道是否有溢出了） 你指的溢出是什么溢出呀，是survivor溢出吗，这个基本不可能，我的Desired survivor size 751619272 bytes(716m). Desired survivor size 751619272 bytes, new threshold 3 (max 3) - age 1: 7154464 bytes, 7154464 total - age 2: 5705400 bytes, 12859864 total - age 3: 3511792 bytes, 16371656 total 不可能是溢出情况。 所有是有可能被回收掉了 |
