结论是OOM Killer杀进程源于堆外内存持续增长，根因在于虚拟线程栈配置失控与DirectByteBuffer未释放，叠加NMT未开启致问题被掩盖。

直接说结论：这不是“线程太多”，而是虚拟线程栈配置失控 + DirectByteBuffer 未及时释放，叠加 NMT 未开启导致问题被掩盖。崩溃表象是 OOM Killer 杀进程，根因是堆外内存持续增长突破系统限制。

一、先确认是不是真由虚拟线程栈引发的堆外泄漏

别急着调参数——先验证归因是否准确：

• 用 jcmd <pid> VM.native_memory summary 查看 native memory 中 Thread 和 Internal 段是否异常飙升（尤其 Thread 栈占比 >40%）
• 对比 jcmd <pid> VM.native_memory detail 的多次快照，重点看 “reserved” 和 “committed” 在 Thread 区的增量趋势
• 检查是否大量使用了 DirectByteBuffer（如 Netty PooledByteBufAllocator、自定义零拷贝读写）——这类对象不占堆，但其 cleaner 未触发时会锁住堆外内存

二、堵住虚拟线程栈膨胀的三个关键口子

Java 21+ 虚拟线程默认栈仍是 1MB，数十万并发下光栈就吃掉几十 GB 堆外内存：

• 强制压栈大小：启动加 -XX:MaxVectorSize=256k（不是 -Xss，那是平台线程用的）
• 禁用递归式深度调用：虚拟线程内避免无节制的 lambda 嵌套、层层 try-with-resources、或手动 new VirtualThread().start() 循环创建
• 用结构化并发兜底：改用 StructuredTaskScope 管理生命周期，确保 scope.close() 后所有关联虚拟线程栈可被 JVM 及时回收

三、清理被卡住的 DirectByteBuffer

Netty 或自研通信层常因 channel 关闭遗漏、GC 时机滞后，导致 cleaner 不执行：

• 在连接断开逻辑中显式调用 buffer.cleaner().clean()（需反射，参考知识库中 forceRelease 方法）
• 若用 Netty，升级到 4.1.100+ 并启用 -Dio.netty.noPreferDirect=true 临时规避 direct buffer 分配
• 对高频短连接场景，考虑改用 heap buffer + 显式 copy，用堆内存换堆外稳定

四、上线前必须做的防御性配置

不能靠出问题再排查：

• JVM 启动必加：-XX:NativeMemoryTracking=detail + -XX:+UnlockDiagnosticVMOptions
• 部署脚本集成定时采集：jcmd $PID VM.native_memory summary > /tmp/nmt_$(date +%s).log
• 监控项加一条告警规则：“Thread native memory 24h 增长超 30%”，触发即查 scope 泄漏或 buffer 积压