Java trouble shooting

Java shooting

作者：周忱 | CDO数据交换平台微博：@MinZhou

邮箱：[email protected]

新人培训课程 | 从入门到精通

为什么我的应用这么慢?

Taobao Java Team | zhouchen.zm

Java Troubleshooting

为什么出现OOM?



为什么我的程序半天不动了?



屌丝的工具集


• jps

• jinfo

• jstat

• jstack

• jmap

• jhat

• vmstat

• iostat

• sar

• ps

• top

• free

• pstack

• pmap


示例-分析挂起的Java应用1






示例-分析跑得慢的应用



高富帅的工具集


• jvisualvm

• IBM memory Analysis tools

• Btrace

• TProfiler

• HouseMD

• …

• Perf

• systemtap

• Oprofile

• Google perf-tools

• Intel Vtune

• blktrace

• …


示例-jvisualvm分析跑得慢的应用



基本概念—内存结构



PC寄存器

局部变量区

操作数栈

栈帧

JVM方法栈 JVM堆

本地方法栈

JVM方法区

-Xss

-XX:PermSize –XX:MaxPermSize

-Xms -Xmx

备注：在Hotspot中本地方法栈和JVM方法栈是同一个，因此也可用-Xss控制

基本概念—内存分配1、堆上分配

大多数情况在eden上分配，偶尔会直接在old上分配细节取决于GC的实现这里最重要的优化是TLAB

2、栈上分配原子类型的局部变量或基于EA后标量替换转变为原子类型的局部变量

3、堆外分配DirectByteBufferFileChannel.map或直接使用Unsafe.allocateMemory，但不推荐这种方式



基本概念—内存回收（Garbage Collection）

1、Hotspot认为没有引用的对象是dead的

2、Hotspot将引用分为四种

Strong、Soft、Weak、Phantom

Strong即默认通过Object o=new Object()这种方式赋值的引用；

Soft、Weak、Phantom这三种则都是继承Reference；

在Full GC时会对Reference类型的引用进行特殊处理：Soft：内存不够时一定会被GC、长期不用也会被GC，可通过-XX:SoftRefLRUPolicyMSPerMB来设置；Weak：一定会被GC，当被mark为dead，会在ReferenceQueue中通知；Phantom：本来就没引用，当从jvm heap中释放，会通知



基本概念—分代

经IBM研究，通常运行的程序有98%的对象是临时对象，因此Sun Hotspot对JVM堆采用了分代的方式来管理，以提升GC的效率。



基本概念—JVM堆的分代



Eden S0 S1 Old Generation

New Generation

-XX:SurvivorRatio

-Xmn

备注：通常将对新生代进行的回收称为Minor GC；对旧生代进行的回收称为Major GC，但由于Major GC除并发GC外均需对整个堆进行扫描和回收，因此又称为Full GC。

基本概念—GC算法及其组合



开启 GC Log



-verbose:gc // 可以辅助输出一些详细的GC信息

-XX:+PrintGCDetails // 输出GC详细信息

-XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间

-XX:+PrintGCDateStamps // GC发生的时间信息

-XX:+PrintHeapAtGC // 在GC前后输出堆中各个区域的大小

-Xloggc:[file] // 将GC信息输出到单独的文件中

gc的日志拿下来后可使用GCLogViewer或gchisto进行分析。

ParNew GC Log



39.910: [GC 39.910: [ParNew: 261760K->0K(261952K), 0.2314667 secs] 262017K->26386K(1048384K), 0.2318679 secs]

CMS GC Log



40.146: [GC [1 CMS-initial-mark: 26386K(786432K)] 26404K(1048384K), 0.0074495 secs]

40.154: [CMS-concurrent-mark-start]

40.683: [CMS-concurrent-mark: 0.521/0.529 secs]

40.683: [CMS-concurrent-preclean-start]

40.701: [CMS-concurrent-preclean: 0.017/0.018 secs]

40.704: [GC40.704: [Rescan (parallel) , 0.1790103 secs]40.883: [weak refs processing, 0.0100966 secs] [1 CMS-remark: 26386K(786432K)] 52644K(1048384K), 0.1897792 secs]

40.894: [CMS-concurrent-sweep-start]

41.020: [CMS-concurrent-sweep: 0.126/0.126 secs]

41.020: [CMS-concurrent-reset-start]

41.147: [CMS-concurrent-reset: 0.127/0.127 secs] CMS GC 详解

https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs

https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs

示例-分析gc overhead OOM



示例-分析Permgen OOM



示例-分析堆外内存占用






Q & A

作者：周忱 | CDO数据交换平台微博：@MinZhou

邮箱：[email protected]



Documents

Java trouble shooting