java stw_java 中STW现象解决

本文探讨了Java中的Stop-The-World (STW)现象,包括由dump线程、死锁检查和堆dump引发的STW。通过调整JVM垃圾回收参数和选择适合的垃圾收集器,如CMS收集器,可以减少STW停顿时间。然而,这可能导致总垃圾回收时间增加和内存碎片。此外,合理设置堆大小和及时释放无用对象也是优化STW的重要策略。
摘要由CSDN通过智能技术生成

先自己弄个问题

产生这个STW问题有 dump线程 死锁检查 堆dupm

/**产生stw其它几个因素:

* dump线程

* 死锁检查

* 堆dupm

* 垃圾回收算法:为让stw时间较长,增大年老代空间和选用serial old垃圾算法进行回收老年代

*

*

* jvm垃圾回收参数:-Xms512m -Xmx512m -Xmn4m -XX:+PrintGCDetails -XX:+UseSerialGC

*

* @author zhanghua

*

*/

public class GenerateSTW {

/**

* 通过集合引用对象,保证对象不被gc回收

*/

private List content=new ArrayList();

public static void main(String[] args) {

GenerateSTW stw=new GenerateSTW();

stw.start();

}

private void start() {

while(true){

try {

content.add(new byte[1024]);

} catch (OutOfMemoryError e) {

//在不可以分配的时候,进行清理部分空间,继续运行,这样会很快产生下一次垃圾回收

for(int i=0;i<1024;i++){

content.remove(i);

}

}

}

}

}

复制代码

是否有方法尽可能减少一次STW停顿时间?由此带来的弊端是什么?

答:减少一次STW停顿时间,我这里从三个方面回答,

1、个是垃圾算法选择

垃圾算法选择:现在都是多核cpu,可以采用并行和并发收集器,如果是响应时间优化的系统应用 ,则jdk6版本一般

选择的垃圾回收算法是:XX:+UseConcMarkSweepGC,即cms收集器,这个收集器垃圾回收时间短,但是垃圾回收总时间变长,使的降低吞

吐量,算法使用的是标记-清除,并发收集器不对内存空间进行压缩,整理,所以运行一段时间以后会产生"碎片",使得运行效率降低.

CMSFullGCsBeforeCompaction此值设置运行多少次GC以后对内存空间进行压缩

2、一个是程序使用堆设置

程序使用堆设置:应该根据程序运行情况,通过Jvm垃圾回收分析,设置一个比较合适的堆大小,不能一意味的将堆设置过大,导致

程序回收很大一块空间,所以会导致stw时间较长,

3、无用对象尽早释放

无用对象尽早释放:使用的对象,如果没有用,尽早设置null,尽量在年轻代将对象进行回收掉,可以减少full gc停顿时长

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值