在Java 8 Update 45中,将这些选项添加到java调用中:
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintSafepointStatistics
-XX:PrintSafepointStatisticsCount=1
向我显示这些统计数据:
vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count
3679.229: no vm operation [ 72 1 2 ] [ 6016 0 6016 0 0 ] 1
2015-05-22T11:25:27.519+0200: Total time for which application threads were stopped: 6.0168551 seconds, Stopping threads took: 6.0164099 seconds
这里的问题是时间长了Stopping threads.在这个例子中,它是6秒,这已经是我们的应用程序的一个问题,但我已经看到更大的时间,在一个实例(没有完整的日志记录,但)相当于几乎一分钟.
VM操作(此处no vm operation:)是变化的.我也看到了,例如RevokeBias,G1IncCollectionPause或GCG_Operation.而且,page_trap_count似乎无关紧要.我所看到的例子,其中是0,和其他人在那里为2一致,不过,是时候总是体现在价值观spin和sync.
我寻找那些定时值的深入的解释spin和sync …
我们遇到以下问题:在我们的某些 Linux机器上,使用特洛伊库和G1 GC的Java应用程序将使用以下类型的消息快速崩溃:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00002aaaaaef81d1, pid=31063, tid=1141000512
JRE version: 6.0_29-b11
Java VM: Java HotSpot(TM) 64-Bit Server VM (20.4-b02 mixed mode linux-amd64 )
Problematic frame:
J gnu.trove.impl.hash.TObjectHash.insertKey(Ljava/lang/Object;)I
这里让我感到震惊的是有问题的框架,它总是一样的.我习惯了这里出现的一些库,但从来没有使用Java代码.奇怪的是,一些应该具有相同设置的机器不会受到影响.在Windows上,我也从未见过这个.最近的Java 7版本仍然存在这个问题.从G1 GC切换到任何其他GC会立即解决问题.我们使用由Maven解决的特洛伊库,在那里尝试了几个版本,包括3.0.3 - 总是同样的问题.
有谁知道这可能是什么原因？任何已知的G1 GC错误？是否以特殊的方式编译了特洛伊,这可能会造成这个问题？
更新:不同的应用程序,不同的服务器,最新的Java(7u5),类似的问题:
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00002aadb7a38093, pid=14100, tid=46925573367184
JRE version: 7.0_05-b05
Java VM: Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode linux-amd64 compressed …在我们的某些应用程序从CMS转移到G1时,我注意到其中一个应用程序的启动时间延长了4倍.由于GC循环导致的应用程序停止时间不是原因.在比较应用程序行为时,我发现这个在启动后(在一堆12G中)携带了高达2.5亿个活动对象.进一步调查显示,在前500万次分配期间,应用程序的速度正常,但随着活动对象池的增大,性能会越来越差.
进一步的实验表明,一旦达到一定的活动对象阈值,使用G1时新对象的分配确实会减慢.我发现活动对象数量增加一倍似乎在分配所需的时间上增加了大约2.5倍.对于其他GC引擎,因子只有2.这确实可以解释减速.
有两个问题让我怀疑这个结论:
所以:如果有人可以告诉我我的观察结果是正确的,并且可能指向一些解释性文件,或者某些有关该领域的建议,那将是很棒的.或者,有人告诉我我做错了什么.:)
这是一个简短的测试用例(多次运行,取平均值,扣除显示的垃圾收集时间):
import java.util.HashMap;
/**
* Allocator demonstrates the dependency between number of live objects
* and allocation speed, using various GC algorithms.
* Call it using, e.g.:
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime -XX:+UseG1GC
* java Allocator -Xmx12g -Xms12g -XX:+PrintGCApplicationStoppedTime
* Deduct stopped times from execution time.
*/
public class Allocator {
public static void main(String[] args) {
timer(2000000, true);
for (int i = 1000000; i <= 32000000; i*=2) {
timer(i, false);
}
for …