【JVM.4】调优案例分析与实战

之前已经介绍过处理Java虚拟机内存问题的知识与工具,在处理实际项目的问题时,除了知识与工具外,经验同样是一个很重要的因素。本章会介绍一些具有代表性的案例。

本章的内容推荐还是原文全篇看完的好,实在不方便摘取重点做记录。

重中之重就是:多动手使用虚拟机工具监控系统的内存分配、GC情况

一.案例分析

1.  高性能硬件上的程序不熟策略(控制Full FC频率是关键。也深夜定时任务的方式触发Full GC)

2.  集群间同步导致的内存溢出(集群同步时,可以允许读操作频繁,但不应当有过于频繁的写操作)

3.  堆外内存导致德溢出错误(Direct Memory 不能像新生代、老年代那样,发现空间不足了就通知收集器进行垃圾回收,只能等待老年代内存满了后执行Full GC。也可以手动catch异常,执行“System.gc”。需要注意“-XX:+DisableExplicitGC”开关)

4.  外部命令导致系统缓慢(Java的Runtime.getRuntime().exec()方法的执行过程,首先克隆一个和当前虚拟机拥有一样环境变量的进程,再用这个新的进程去执行外部命令,最后退出这个进程。如果频繁操作的话,系统消耗会很大)

5.  服务器JVM进程崩溃(当系统中出现大量等待的线程和Socket连接,超过虚拟机承受能力使JVM崩溃时,解决使线程等待的等待源的速度,将异步调用改为生产者/消费者模式)

6.  不恰当数据结构导致内存占用过大(HashMap<long,long>的空间使用率为 16B/88B)

    88B的由来:在HashMap<long,long>结构中,只有Key和Value所存放的两个长整型数据为有效数据,工16B。这两个长整型数据包装成java.lang.Long对象之后,分别具有8B的MarkWord、8B的Klass指针,再加8B存储数据的long值。

    在这两个Long对象组成Map。Entry之后,又多了16B的对象头,然后一个8B的next字段和8B的int型hash值,为了对齐还必须添加4B的空白填充,最后在再HashMap中对这个Entry的8B引用,这样增加两个长整型数字,

    实际消耗的内存为: Long(24B * 2) + Entry(32B) + HashMap Ref(8B) = 88B

7.  由Windows虚拟内存导致德长时间停顿()

二.Eclipse运行速度调优

1.  使用VisualGC查看Eclipse启动信息(......Full GC 触发19次,耗时3.166秒,Minor GC 触发378次,耗时0.983秒......)

2.  JDK升级()

3.  编译时间和类加载时间的优化()

4.  调整内存设置控制垃圾收集频率(查看GC日志。老年代空间耗尽时,会发生一次Full GC,并且老年代容量扩容。可以设置老年代的初始容量,避免自动扩容。新生代也相同)

    (使用jstat-gccause查看,发现代码中有调用System.gc()显式触发GC,我们可以加入 -XX:+DisableExplicitGC 屏蔽掉System.gc())

5.  选择收集器减低延迟(选择并发收集器,降低延迟)

上一篇:cannot locate symbol "atof" referenced by错误分析


下一篇:在Android Studio进行“简单配置”单元测试(Android Junit)