凌晨四点，一台订单服务的 Pod 重启了三次。 不是 OOM killer，是老年代也正常，JVM 挂的时候堆才用了 2G（最大 4G）。诡异的是 Metaspace 占了 1.2G，而且每次重启后不到两小时又回到 1.2G。 翻 Metaspace 的内存分布，Class Count 已经飙到 15 万。正常一个 Spring Boot 服务也就 1-2 万个类。这多出来的十几万个类哪来的？ 顺着加载的类名找过去——全部是 com.alibaba.qlexpress.ExpressionRunner 加上不同的数字后缀： com.alibaba.qlexpress.ExpressionRunner$1 com.alibaba.qlexpress.ExpressionRunner$2 com.alibaba.qlexpress.ExpressionRunner$3 ... com.alibaba.qlexpress.ExpressionRunner$154327 QLExpress 每次执行 QLExpressRunner.execute() 时，会把规则脚本编译成字节码，然后通过一....

公司有个规则引擎服务，每天运营要更新几百条风控规则。QLExpress 每次执行规则都会编译生成一个匿名类，然后装进 JVM 的 Metaspace。运行了两周之后，服务开始频繁 Full GC，再后来直接 Metaspace OOM 崩了。重启能续命两周，但规则数量只增不减，两周变成十天，十天变成一周，最后每天都得重启。 这个问题在脚本引擎场景下几乎必现。GroovyShell、QLExpress、Aviator，甚至 Nashorn，只要是"动态编译 → 生成类 → 装载到 JVM"的模式，都会往 Metaspace 里塞东西。而且 Metaspace 默认没有上限——它只会一直涨，直到物理内存耗尽。 今天聊聊怎么用 ClassLoader 隔离 + 定时回收，让 Metaspace 不炸。 Metaspace 里到底装了什么 Java 8 以前叫 PermGen，Java 8 以后改名为 Metaspace。换了个名字，但干的活一样——存类的元数据。 你写的每一个类，编译后的字节码，字段名、方法名、注解信息、常量池，全部放在这里。普通的 Java 类在应用启动时加载一次，之后不....

导语 内存泄漏是 Java 应用中最隐蔽的性能问题之一，它可能在系统运行数月甚至数年后才会爆发，导致 OOM (OutOfMemoryError) 并使服务完全不可用。当 OOM 发生时，开发者往往面临两个挑战：一是如何快速定位问题，二是如何在问题发生前预警。 本文将深入探讨 JVM 内存泄漏的监控策略，包括： 内存泄漏的识别与分析方法 基于 SpringBoot 的 OOM 预警机制设计 Heap Dump 自动采集策略 生产级监控系统的实现 通过本文的技术方案，您将能够在 OOM 发生前及时发现内存异常，并自动采集堆转储文件，为问题分析提供充分的现场证据。 一、内存泄漏的本质与识别 1.1 内存泄漏的定义 内存泄漏指的是 Java 应用中对象不再被程序使用，但垃圾收集器无法回收它们的现象。这些对象会一直占用内存，直到内存耗尽。 1.2 常见的内存泄漏场景 场景原因示例 静态集合静态集合持有对象引用static List cache = new ArrayList<>(); 监听器未移除注册的监听器未注销GUI 组件、事件监听器 连接未关闭数据库连接、网络连接....