java 正则去掉div_Java常见问题排查

• NoSuchMethodException
• 应用没响应
• 调用另一应用超时
• java.lang.OutOfMemoryError
• CPU us高
• CPU sy高
• CPU iowait高
• Java进程退出

NoSuchMethodException

• 出现这种现象的原因

1. Java ClassLoader机制
2. Java里让人极度头疼的Jar版本冲突问题

• 同类型的问题

1. ClassNotFoundException/NoClassDefFoundError/ClassCastException

• 排查方法

1. -XX:+TraceClassLoading
2. jar –tvf *.jar

• 解决方法

1. mvn pom里去除不需要的版本provided
2. 在打包阶段就尽可能避免掉版本冲突的问题

应用没响应

• 出现这种现象的典型原因

1. 资源被耗光(CPU、内存)
2. 死锁
3. 处理线程池耗光

• 表现

1. HTTP响应返回499、502、504

• 排查方法

1. 死锁 1. jstack –l 2. 仔细看线程堆栈信息
2. 处理线程池耗光 查看从请求进来的路径上经过的处理线程池中的线程状况

• 解决方法

1. 死锁 想办法解开锁
2. 处理线程池耗光，加大线程池 or 减小超时时间等

调用另一应用超时

• 原因

1. 服务端响应慢
2. 调用端或服务端GC频繁
3. 调用端或服务端CPU消耗严重  反序列化失败
4. 网络问题

• 排查方法

1. 查看服务端对应的日志和响应时间监控信息
2. 查看调用端和服务端的gc log
3. 查看调用端和服务端的CPU利用率
4. 查看有没有反序列化失败的log
5. 查看网络的重传率
6. EagleEye

java.lang.OutOfMemoryError

• GC overhead limit exceeded
• Java Heap Space
• Unable to create new native thread  PermGen Space
• Direct buffer memory
• Map failed
• request {} bytes for {}. Out of swap space?

• GC overhead limit exceeded/Java Heap Space

1. Java Heap分配不出需要的内存了
2. 拿到HeapDump文件，1 -XX:+HeapDumpOnOutOfMemoryError 2 jmap –dump:file=,format=b [pid] 3 gcore [pid]
3. 分析HeapDump文件，MAT – Dominator Tree
4. 根据MAT分析的结果来定位到代码，btrace

• 排查方法

分析HeapDump文件时可能会碰到  占用的内存并不多

 分配了一个巨大的对象

 grep –i ‘allocating large’ 日志文件(必须是ali jdk)

 死循环

•  jstack

java.lang.OutOfMemoryError

 GC overhead limit exceeded/Java Heap Space  解决方法

 根据定位到的消耗了较多内存的代码，针对性的处理  例如

 自增长的数据结构对象没限制大小  引用未释放，造成内存泄露

java.lang.OutOfMemoryError

 GC overhead limit exceeded/Java Heap Space  同类型的问题

 CMS GC频繁

 CMS GC频繁要注意还有可能是由于缺少一个参数

 -XX:+UseCMSInitiatingOccupancyOnly  Full GC频繁

 还有可能是因为悲观策略

java.lang.OutOfMemoryError

 Unable to create new native thread  出现这个现象的原因

 线程数超过了ulimit限制

 会导致执行ps等出现resource temporarily unavailable  出现时可以先临时调整下ulimit，以便能操作

 线程数超过了kernel.pid_max

 会导致执行ps等出现resource temporarily unavailable  只能重启

 机器完全没有内存了

 这种可能性通常很小，原因是...

java.lang.OutOfMemoryError

 Unable to create new native thread  排查方法

 ps –eLf | grep java –c  cat /proc/[pid]/limits

 如果太小，可以调大点max open processes值  sysctl –a | grep kernel.pid_max

 如果真的是线程创建太多了

 jstack 有线程名的话通常会比较好排查  btrace

 new Thread || new ThreadPoolExecutor

java.lang.OutOfMemoryError

 Unable to create new native thread  解决方法

 线程池并限制大小

 对使用到的API一定要非常清楚

 例如很容易误用的netty client

java.lang.OutOfMemoryError

 PermGen Space

 出现这个问题的原因

 PermGen被用满

 PermGen的使用和回收

java.lang.OutOfMemoryError

 PermGen Space  排查方法

 btrace

 ClassLoader.defineClass

java.lang.OutOfMemoryError

 PermGen Space  解决方法

 确认是不是真的需要装载那么多，如果是  调大PermSize

 如果不是

 控制ClassLoader

 常见于Groovy的误用

java.lang.OutOfMemoryError

 Direct buffer memory  出现这个现象的原因

 Direct ByteBuffer使用超出了限制的大小  默认的大小为-Xmx

 jinfo -flags

 Java中只能通过ByteBuffer.allocateDirect来使用Direct ByteBuffer

 java.lang.OutOfMemoryError

 Direct buffer memory  排查方法

 btrace

 ByteBuffer.allocateDirect

 java.lang.OutOfMemoryError

 Direct buffer memory  解决方法

 如果真的是不够用，在内存够用的情况下可以调大  -XX:MaxDirectMemorySize

 常见的是类似网络通信未做限流这种

 java.lang.OutOfMemoryError

 Map failed

 出现这个现象的原因

 FileChannel mapped的文件超出了限制  vm.max_map_count

 java.lang.OutOfMemoryError

 Map failed  排查方法

 btrace

 FileChannel.map

 看看是不是加了-XX:+DisableExplicitGC参数

 java.lang.OutOfMemoryError

 Map failed  解决方法

 有必要的话调大vm.max_map_count

 如map file存活个数其实不多则去掉-XX:+DisableExplicitGC

 在CMS GC的情况下，增加-XX:+ExplicitGCInvokesConcurrent

 java.lang.OutOfMemoryError

 request {} bytes for {}. Out of swap space?  出现这个现象的原因

 地址空间不够用  物理内存耗光

 java.lang.OutOfMemoryError

 request {} bytes for {}. Out of swap space?  排查方法

 物理内存耗光  按经验

 btrace

 Deflater.init | Deflater.end | Inflater.init | Inflater.end

 强制执行full gc

 jmap –histo:live [pid]

 如果执行几次后内存明显下降，则基本是Direct ByteBuffer造 成的

 google Perftools

 java.lang.OutOfMemoryError

 request {} bytes for {}. Out of swap space?  解决方法

 地址空间不够

 升级到64 bit

 物理内存耗光

 Inflater/Deflater问题的话则显式调用end

 Direct ByteBuffer问题可以调小-XX:MaxDirectMemorySize  其他case根据google perftools显示的来跟进

 CPU us高

 出现这个现象的原因

 CMS GC/Full GC频繁

 代码中出现非常耗CPU的操作  整体代码的消耗

 CPU us高

 排查方法

 CMS GC/Full GC频繁

 查看gc log，或jstat –gcutil [pid] 1000 10  代码中出现非常耗CPU的操作

 top –H + jstack，做pid到nid的16进制转化  printf '0x%x'

 整体代码的消耗

 top –H看到每个线程消耗都差不多，而且不断变化

 CPU us高

 解决方法

 CMS GC/Full GC频繁

 详见前面的内容

 代码中出现非常耗CPU的操作

 通常需要进一步btrace

 正则匹配某些字符串造成cpu us高的case

 也不一定很好处理

 覆盖Exception的getCause造成cpu us高的case

 整体代码的消耗  通常很难搞

 CPU sy高

 出现这个现象的原因  锁竞争激烈

 线程主动切换频繁  还有一个经验是

 linux 2.6.32后的高精度的问题

 CPU sy高

 排查方法  jstack

 看看锁状况

 看看是不是有主动线程切换等  btrace

 AbstractQueuedSynchronizer.ConditionObject.awaitNanos

 CPU sy高

 解决方法

 锁竞争激烈

 根据业务实现要求合理做锁粒度控制，或引入无锁数据结构  线程主动切换

 改为通知机制  高精度问题

 至少调大到1ms+的await

 CPU iowait高

 出现这个现象的原因

 io读写操作频繁

 CPU iowait高

 排查方法

 确认硬件状况

 例如raid卡的cache策略  借助系统工具

 blktrace+debugfs  iotop

 btrace

 CPU iowait高

 解决方法

 提升dirty page cache  cache

 同步写转异步写

 随机写转顺序写

 实在搞不定

 昂贵的硬件

 Java进程退出

 排查方法

 查看生成的hs_err_pid[pid].log

 确保core dump已打开，cat /proc/[pid]/limits  dmesg | grep –i kill

 根据core dump文件做相应的分析

 gdb [java路径] core文件  c调试技巧

 Java进程退出  crash demo

 jinfo -flag FLSLargestBlockCoalesceProximity

 Java进程退出

 常见的cases

 native stack溢出导致java进程退出的case

 编译不了某些代码导致的Java进程退出的case

- XX:CompileCommand=exclude,the/package/and/Class,methodName

 内存问题导致的进程退出的case  JVM自身bug导致退出的case