隐匿在 Linux 背后的机制

稍微大的点系统都会有很多依赖的组件，这些组件底层都有可能会用到一些反射 或者 字节码框架 , 会生成一些你看不懂类名的类

一旦第三方框架出现问题 , 你的系统很有可能也会受影响

调大元空间 , 有监控系统的设置报警机制 , 给自己系统争取一些缓冲时间也是有必要的

5.-XX:TraceClassLoading -XX:TraceClassUnloading

追踪类加载和类卸载的情况 , 可以在 Tomcat 的 catalina.out 日志文件中

打印出来JVM中加载了哪些类，卸载了哪些类

6.-XX:SoftRefLRUPolicyMSPerMB: JVM 可以忍受多久 软引用不被回收

如果是 0 则每次都会把软引用回收掉释放内存

有一个情况是反射在 15 次后会动态生成一些软引用类来提高反射的效率 , 当 ygc 的时候把这些软应用给回收了

但是它们的类加载器或者一些奇怪名字的类还在元空间 , 那下次要用这个反射对象的时候又得重新创建

就造成了元空间慢慢无限增大从而触发 OOM , 建议这个参数设置 2000 - 5000 单位是: ms

7.-XX：+DisableExplicitGC: 关闭显示的调用 System.gc() , System.gc() 是触发类似 full gc 的操作

开启 or 关闭 有两个情况

关闭: 防止 team 里有刚入职的小天才写完一个业务逻辑就给你来一个 System.gc() 来优化内存 (别问 问那个小天才就是我)

开启: 项目里面有 Nio 相关的操作会用到直接内存 , 在 Java 中是 DirecByteBuffer 对象来申请的

在某些不合理的情况下导致控制这块区域的 DirecByteBuffer 会晋升到老年代

Nio 在申请堆外内存空间不足的时候会手动调用 System.gc() 去回收 DirecByteBuffer 堆外内存

有用到 Nio 的系统把这个参数关掉是有一定概率发生 Direct buffer memory 的

关闭还是打开取决于你自己的系统 , 以及能不能做到 code review 不让程序员自己去显示的调用 System.gc()

8.-XX:G1MixedGCCountTarget: 设置垃圾回收混合回收阶段，最多可以拆成几次回收

G1 的垃圾回收是分为 初始标记、并发标记、最终标记、混合回收 这几个阶段的

其中混合回收是可以并发的反复回收多次 , 这样的好处是避免单次停顿回收 stw 时间太长

停止系统一会儿 , 回收掉一些 Region , 再让系统运行一会儿 , 然后再次停止系统一会儿 , 再次回收掉一些 Region

这样可以尽可能让系统不要停顿时间过长 , 可以在多次回收的间隙 , 也运行一下

在一定程度上可以防止部分接口相应超时

六、小结

相信你看到这里 , 应该对高并发系统中 对象如何吃 JVM 内存 频繁 遇到 gc 如何解决 已经有所了解了 。

尽管有效的解决办法仍然是加机器 , 但是加多少台机器 , 怎么加机器 , JVM 参数要如何设置都有所了解了。