jvm内存管理需精细调优而非简单设参：年轻代比例失衡会加剧minor gc频率或提前晋升；静态引用、threadlocal未清理及jni类路径失效等隐性问题易引发缓慢内存泄漏；栈空间不足则导致stackoverflowerror。
JVM内存管理不是“设完参数就完事”的事情，很多问题表面是OOM或卡顿，根子却在内存区域划分、对象生命周期和参数联动关系上。真正踩过坑的人知道：错配一个比例，可能让GC频率翻倍；忽略一个作用域，能让类路径彻底失效。
年轻代比例失衡导致频繁Minor GC
Eden区太小，对象刚分配就触发Minor GC；太大又会让存活对象快速填满Survivor区，提前晋升到老年代。关键不在绝对大小，而在Eden与Survivor的配比是否匹配实际对象存活率。
- -XX:SurvivorRatio=8 是通用值，但若业务中大量对象存活2~3次GC才死亡，应调小该值（如设为4），扩大Survivor空间
- 不要只看SurvivorRatio，要结合GC日志里的 “age threshold” 和 “Desired survivor size” 判断实际晋升阈值是否合理
- 避免盲目增大-Xmn——新生代过大可能挤占老年代空间，反而诱发Full GC
静态引用与缓存引发隐性内存泄漏
静态集合、单例持有的Map、未清理的ThreadLocal变量，都会让本该回收的对象长期驻留堆中。这类泄漏不会立刻报错，而是缓慢堆积，直到某次GC再也腾不出空间。
- 缓存必须带驱逐策略（LRU、TTL）或使用WeakReference/SoftReference包装value
- ThreadLocal使用后务必调用remove()，尤其在线程池场景下，线程复用会导致旧值残留
- 检查第三方SDK是否注册了静态监听器或回调，它们常被忽视却持有Activity或Service强引用
JNI环境下的类路径失效陷阱
通过C/C++调用JNI创建JVM时，-Djava.class.path传入的字符串若来自栈上局部变量（如char path[] = "/xxx"），JVM启动后该内存可能已被释放，导致类找不到——这在Debian等严格内存管理的系统上尤为明显。
- 必须用malloc或strdup动态分配类路径字符串，并确保其生命周期覆盖整个JVM运行期
- 推荐封装为全局变量或由JVM启动后统一管理，避免C层变量作用域提前结束
- 验证方式：启动后调用ClassLoader.getSystemClassLoader().getResource("")，确认基础路径可访问
栈空间不足与递归失控
每个线程的虚拟机栈默认1MB（-Xss），看似充裕，但在深度嵌套调用、大量局部变量或AOP代理层层包裹时，极易触达上限。StackOverflowError不抛内存溢出，但一样导致服务不可用。
- 排查时重点看异常堆栈深度——连续几十层相同方法调用，基本锁定递归或循环代理
- toString()、equals()、hashCode()重写时，避免无意调用自身或同类其他方法形成隐式递归
- 对高并发短连接场景（如Netty handler），可适当调小-Xss（如256k），但需同步压测验证稳定性
