# 案例汇总

优化环境

  1. OOM产生的原因多种多样,有些程序未必产生OOM,不断FGC(CPU飙高,但内存回收特别少) (上面案例)

    调优实战-常用工具 中第一个案例.

  2. 有一个50万PV的资料类网站(从磁盘提取文档到内存)原服务器32位,1.5G 的堆,用户反馈网站比较缓慢,因此公司决定升级,新的服务器为64位,16G 的堆内存,结果用户反馈卡顿十分严重,反而比以前效率更低了

    1. 为什么原网站慢? 很多用户浏览数据,很多数据load到内存,内存不足,频繁GC,STW长,响应时间变慢
    2. 为什么会更卡顿? 内存越大,FGC时间越长
    3. 咋办? PS -> PN + CMS 或者 G1
  3. 系统CPU经常100%,如何调优?(面试高频) CPU100%那么一定有线程在占用系统资源

    1. 找出哪个进程cpu高(top)
    2. 该进程中的哪个线程cpu高(top -Hp)
    3. 导出该线程的堆栈 (jstack)
    4. 查找哪个方法(栈帧)消耗时间 (jstack)
    5. 工作线程占比高 | 垃圾回收线程占比高
  4. 系统内存飙高,如何查找问题?(面试高频)

    1. 导出堆内存 (jmap)
    2. 分析 (相关分析工具 jhat jvisualvm mat jprofiler ... )
  5. 如何监控JVM

    • jstat
    • jvisualvm
    • jprofiler
    • arthas top...
  6. 线程池不当运用产生OOM问题(见上) 不断的往List里加对象(实在太LOW)

  7. smile jira问题 实际系统不断重启 解决问题 加内存 + 更换垃圾回收器 G1 真正问题在哪儿?不知道

  8. tomcat http-header-size过大问题(Hector)

  9. lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace) LambdaGC.java -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails

   java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1574)
          at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:79)
          at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:519)
          at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:494)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:494)
          at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:391)
          at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1134)
          at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
          at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
          at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
          at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
          at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
          at javax.management.remote.rmi.RMIConnectorServer.encodeJRMPStub(RMIConnectorServer.java:727)
          at javax.management.remote.rmi.RMIConnectorServer.encodeStub(RMIConnectorServer.java:719)
          at javax.management.remote.rmi.RMIConnectorServer.encodeStubInAddress(RMIConnectorServer.java:690)
          at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:439)
          at sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:550)
          at sun.management.Agent.startLocalManagementAgent(Agent.java:137)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
  1. 直接内存溢出问题(少见) 《深入理解Java虚拟机》P59,使用Unsafe分配直接内存,或者使用NIO的问题

  2. 栈溢出问题 -Xss设定太小

  3. 比较一下这两段程序的异同,分析哪一个是更优的写法:

Object o = null;
for(int i=0; i<100; i++) {
  o = new Object();
  //业务处理
}
1
2
3
4
5
for(int i=0; i<100; i++) {
  Object o = new Object();
}
1
2
3
  1. 重写finalize引发频繁GC 小米云,HBase同步系统,系统通过nginx访问超时报警,最后排查,C++程序员重写finalize引发频繁GC问题 为什么C++程序员会重写finalize?(new delete) finalize耗时比较长(200ms)

  2. 如果有一个系统,内存一直消耗不超过10%,但是观察GC日志,发现FGC总是频繁产生,会是什么引起的? System.gc() (这个比较Low)

  3. Distuptor有个可以设置链的长度,如果过大,然后对象大,消费完不主动释放,会溢出 (来自 死物风情)

  4. 用jvm都会溢出,mycat用崩过,1.6.5某个临时版本解析sql子查询算法有问题,9个exists的联合sql就导致生成几百万的对象(来自 死物风情)

  5. new 大量线程,会产生 native thread OOM,(low)应该用线程池, 解决方案:减少堆空间(太TMlow了),预留更多内存产生native thread JVM内存占物理内存比例 50% - 80%

上次更新时间: 2020/11/17 上午12:35:40