建设网站群的好处,网站服务内容怎样选,seo 专业为网站建设,模板网传奇手游文章目录前言一、概述二、案例二三、案例#xff1a;方法区内存溢出1、代码:LambdaGC.java2、元空间内存溢出日志3、分析4、疑问*****四、案例#xff1a;直接内存溢出问题#xff08;少见#xff09;#xff08;尽量不说#xff09;五、案例#xff1a;栈内存溢出问题1…
文章目录前言一、概述二、案例二三、案例方法区内存溢出1、代码:LambdaGC.java2、元空间内存溢出日志3、分析4、疑问*****四、案例直接内存溢出问题少见尽量不说五、案例栈内存溢出问题1、栈溢出原因2、案例递归a、代码b、结果c、原因d、解决方法代码分析1、代码2、分析七、重写finalize引发频繁GC1、概述2、问题3、答案4、案例八、new 大量线程导致OOM太LOW前言
JDK中的 垃圾回收器 JDK8PSPOJDK9G1JDK11CMS就淘汰了完成历史使命了JDK13 学完这篇博客可以在简历上写 有过JVM调优的经验 但是不能写精通哦了。
一、概述
OOM产生的原因多种多样有些程序未必产生OOM不断FGC(CPU飙高但内存回收特别少) 上个博文的最后的案例七.1
硬件升级系统反而卡顿的问题见上线程池不当运用产生OOM问题见上 不断的往List里加对象实在太LOW了smile jira问题 实际系统不断重启 解决问题加内存 更换垃圾回收器 G1 真正问题在哪儿不知道
二、案例二
tomcat http-header-size过大问题
三、案例方法区内存溢出
lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace)不是那么真实面试时尽量不要说这个 只是想表达方法区也会内存溢出OutOfMemoryErrorlambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace)
1、代码:LambdaGC.java
启动参数-XX:MaxMetaspaceSize9M -XX:PrintGCDetails
package com.mashibing.jvm.c5_gc;public class LambdaGC {public static void main(String[] args) {for(;;) {I i C::n;}}public static interface I {void m();}public static class C {static void n() {System.out.println(hello);}}
}
2、元空间内存溢出日志
C:\Program Files\Java\jdk1.8.0_181\bin\java.exe -XX:MaxMetaspaceSize9M -XX:PrintGCDetails -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\lib\idea_rt.jar49316:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\bin -Dfile.encodingUTF-8 -classpath C:\Program Files\Java\jdk1.8.0_181\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\rt.jar;C:\work\ijprojects\JVM\out\production\JVM;C:\work\ijprojects\ObjectSize\out\artifacts\ObjectSize_jar\ObjectSize.jar com.mashibing.jvm.gc.LambdaGC
[GC (Metadata GC Threshold) [PSYoungGen: 11341K-1880K(38400K)] 11341K-1888K(125952K), 0.0022190 secs] [Times: user0.00 sys0.00, real0.00 secs]
[Full GC (Metadata GC Threshold) [PSYoungGen: 1880K-0K(38400K)] [ParOldGen: 8K-1777K(35328K)] 1888K-1777K(73728K), [Metaspace: 8164K-8164K(1056768K)], 0.0100681 secs] [Times: user0.02 sys0.00, real0.01 secs]
[GC (Last ditch collection) [PSYoungGen: 0K-0K(38400K)] 1777K-1777K(73728K), 0.0005698 secs] [Times: user0.00 sys0.00, real0.00 secs]
[Full GC (Last ditch collection) [PSYoungGen: 0K-0K(38400K)] [ParOldGen: 1777K-1629K(67584K)] 1777K-1629K(105984K), [Metaspace: 8164K-8156K(1056768K)], 0.0124299 secs] [Times: user0.06 sys0.00, real0.01 secs]
java.lang.reflect.InvocationTargetExceptionat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:388)at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
Caused by: java.lang.OutOfMemoryError: Compressed class spaceat sun.misc.Unsafe.defineClass(Native Method)at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63)at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:394)at java.security.AccessController.doPrivileged(Native Method)at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:393)at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:112)at sun.reflect.ReflectionFactory.generateConstructor(ReflectionFactory.java:398)at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:360)at 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)
3、分析
Compressed class space Compressed class 是对象头的压缩指针在方法区中有一块内存专门是给压缩后的class用的一旦占满之后就会内存溢出。这里通过space 可以看出 是方法区的内存溢出。通过案例可以知道 元空间也是可以产生内存溢出的
4、疑问*****
为什么lambda表达式导致方法区溢出问题大多数不应该在堆中吗而且这里为什么不会在栈中的局部变量中呢而会在方法区呢
四、案例直接内存溢出问题少见尽量不说 《深入理解Java虚拟机》P59除非使用Unsafe分配直接内存或者使用NIO的问题会导致直接内存Direct Memory溢出问题 很少见的一般不会搞出这个情况。
五、案例栈内存溢出问题
1、栈溢出原因
-Xss设定太小原因局部方法内对象创建太多了引用也太多了。通过前面JVM知识体系学习六JVM垃圾是什么、GC常用垃圾清除算法、堆内存逻辑分区、栈上分配、对象何时进入老年代、有关老年代新生代的两个问题、常见的垃圾回收器、CMS 的学习知道了 有的对象会 栈上分配所以当多的时候也就会产生栈溢出啦。
2、案例递归
a、代码
package com.mashibing.jvm;public class StackOverFlow {public static void main(String[] args) {m();}static void m() {m();}
}
b、结果 c、原因
栈中是每个的栈针这里有方法的递归所以栈的深度越来越大导致栈的内存溢出。
d、解决方法
设置栈的大小-Xss
代码分析
1、代码
代码1
Object o null;
for(int i0; i100; i) {o new Object();//业务处理
}代码2
for(int i0; i100; i) {Object o new Object();
}2、分析
肯定是第一个代码会好一些。原因 第一个代码栈上只创建一个变量通过循环会创建一个个的实例对象然后变量指向实例对象。当变量指向第二个实例对象时上一个实例对象就没有引用了就会被垃圾回收掉。第二个代码每次都会产生一个对象且有很大可能很多对象不会被回收掉。方法执行完会被释放掉。 综上所述第一个代码好一些。
七、重写finalize引发频繁GC
1、概述
小米云HBase同步系统系统通过nginx访问超时报警最后排查C程序员重写finalize引发频繁GC问题排除情况 nginx访问超时报警发现CPU飙高发现频繁GC再发现对象过多最后发现C程序员重写finalize引发频繁GC问题
2、问题
问题1为什么C程序员会重写finalize问题2为什么重写finalize会导致频繁GC。
3、答案 因为C程序员是手动回收内存的先new 再delete。 C的构造函数和java 一样也需要 new但是C需要手动回收内存但是手动回收内存是析构函数来解析完成的 C 调用delete语句的时候会默认调用 析构函数调用new 语句的时候默认会调用构造函数。所以 delete语句在C里是 手动回收内存要使用的语句。C程序员会理所当然的认为java里面是不是也有一个类似于析构函数这样的东西结果发现有个finalize结果重写了。 为什么造成频繁GC呢 是因为重新的finalize耗时比较长。有可能会达到200ms不确定。这里有一些耗时长的操作如果好多对象同时产生了但是收到时会调用finalize每个都要调用所以回收不过来了就会频繁GC。
4、案例 如果有一个系统内存一直消耗不超过10%但是观察GC日志发现FGC总是频繁产生会是什么引起的 有人手动调用了 System.gc() (这个比较Low)。 -XX:DisableExplictGC弃用System.gc()不管用 FGC
八、new 大量线程导致OOM太LOW
new 大量线程会产生 native thread OOM.解决方案 太low应该用线程池。 太LOW了减少堆空间太TMlow了,预留更多内存产生native thread 经验扩展JVM内存占物理内存 比例 50% - 80%