4、内存瓶颈分析：内存泄漏、内存碎片、GC频繁、大对象堆问题、虚拟内存与物理内存的平衡

内存问题，说实话，是桌面应用里最难缠的对手。它不像CPU那样跑个火焰图就能定位，内存泄漏往往要跑上几个小时甚至几天才会暴露。我这些年调优下来，发现大部分崩溃都跟内存有关。今天咱们就把内存这块硬骨头啃下来。

4.1 内存泄漏：看不见的吞噬者

内存泄漏说白了就是：你申请了一块内存，用完之后忘了还回去。一次两次没事，但积少成多，应用就会越来越卡，最后崩溃。

典型场景：事件监听未解绑

我在项目中遇到过最典型的泄漏，就是事件监听器没移除。比如一个弹窗关闭了，但它的点击事件还挂在全局对象上。弹窗对象明明已经销毁了，但事件回调里还持有它的引用，GC就永远回收不了它。

避坑指南：我曾经接手过一个IM客户端，运行8小时后内存从80MB涨到2GB。查了两天才发现，是WebSocket消息回调里创建了匿名内部类，隐式持有了Activity的引用。解决方案很简单：用弱引用，或者在onDestroy里显式置空。

// 错误写法：匿名内部类隐式持有外部类引用
button.addActionListener(e -> {
    // 这里隐式持有了当前对象的引用
    heavyOperation();
});

// 正确写法：使用弱引用或显式解绑
WeakReference<MyClass> weakRef = new WeakReference<>(this);
button.addActionListener(e -> {
    MyClass instance = weakRef.get();
    if (instance != null) {
        instance.heavyOperation();
    }
});

4.2 内存碎片：明明有空位，却装不下新数据

内存碎片是个很隐蔽的问题。你看着任务管理器里还有500MB空闲，但应用就是报OOM。为什么会这样？因为空闲内存不连续。

我个人的习惯是，在长时间运行的服务端应用里特别关注碎片问题。比如一个图片编辑器，用户反复打开关闭大图，每次分配释放几MB的内存块。时间长了，堆里就布满了小空洞。这时候你想分配一个10MB的连续内存，对不起，没有这么大的连续空间。

内存状态 可用空间 能否分配10MB
连续空闲 500MB ✅ 可以
碎片化空闲 500MB（分散成50个10MB碎片） ❌ 不可以

我的经验：对于碎片问题，JVM的G1GC比CMS好很多，因为它有Region机制。如果你用C++，可以考虑jemalloc或tcmalloc替代系统默认的malloc，它们对碎片控制更好。

4.3 GC频繁：Stop The World的代价

GC频繁是性能杀手。你想想看，应用每秒钟都要停下来做垃圾回收，用户操作能不卡吗？

怎么判断GC是否频繁？

我一般看两个指标：GC暂停时间和GC频率。如果每秒GC超过1次，或者单次暂停超过100ms，那就需要优化了。

// 打印GC日志（JVM参数）
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

// 分析GC日志的关键行
2024-01-15T10:30:45.123+0800: [GC (Allocation Failure) 
  [PSYoungGen: 51200K->1024K(61440K)] 102400K->52424K(204800K), 0.0234567 secs]
// 解读：年轻代从50MB回收到了1MB，总堆从100MB降到了52MB，耗时23ms

注意：GC频繁不一定是内存不够，有时候是对象创建太频繁。我曾经优化过一个报表应用，发现它每秒创建了10万个临时String对象。优化方案很简单：改用StringBuilder，GC频率直接降了80%。

4.4 大对象堆问题：直接进入老年代的庞然大物

大对象，在JVM里指的是超过-XX:PretenureSizeThreshold设置的对象（默认1MB）。这些对象不会经过年轻代，直接分配到老年代。问题在于，老年代的GC（Full GC）比年轻代慢得多。

我记得有个图像处理软件，每次加载高清图片都触发Full GC。查了一下，一张1920x1080的位图，在内存里占8MB左右。这8MB直接进了老年代，老年代很快就满了，然后频繁Full GC。

解决方案：

  • 对大对象使用对象池，复用而不是反复创建
  • 调整-XX:PretenureSizeThreshold，让大对象先在年轻代试试
  • 实在不行，用直接内存（DirectBuffer）绕开堆
// 使用直接内存避免堆压力
ByteBuffer buffer = ByteBuffer.allocateDirect(8 * 1024 * 1024); // 8MB
// 注意：直接内存需要手动释放，否则会泄漏

4.5 虚拟内存与物理内存的平衡

这个问题，很多开发者容易忽略。虚拟内存不是无限大的，物理内存更是有限资源。我见过有人把应用的内存上限设得特别高，结果物理内存不够，系统开始疯狂换页，性能直接崩盘。

核心原则：

  • 虚拟内存设置不要超过物理内存的2倍（32位系统）
  • 实际工作集（Working Set）最好控制在物理内存的60%以内
  • 监控Page Faults/sec，如果持续超过100，说明内存不够用了

我的调优经验：一个3D建模软件，用户反馈操作卡顿。我一看，物理内存16GB，应用设置了12GB的堆。结果系统把大量数据换到了虚拟内存，每次操作都要从磁盘读数据。把堆降到8GB后，反而更流畅了。你想想看，少4GB堆，但换来了零换页，这笔账很划算。

4.6 实战：内存问题排查工具

光说不练假把式。我常用的工具就这几个：

工具 用途 我的用法
VisualVM 堆转储分析 先抓堆快照，看哪些对象占内存最多
MAT (Memory Analyzer) 泄漏嫌疑分析 用Leak Suspects自动找泄漏点
PerfMon 实时监控 看GC频率和内存使用曲线
Valgrind C++内存检测 查野指针和未释放内存

小技巧：排查内存泄漏时，我习惯先做一次Full GC，再抓堆快照。这样能过滤掉那些本应被回收的对象，更容易找到真正的泄漏点。

嗯，内存这块内容比较多，但核心就一句话：少创建、早释放、复用对象、监控曲线。你把这四点做到位了，内存问题基本就解决了一大半。下一章咱们聊聊磁盘I/O的瓶颈，那个坑也不少。

← 上一章 📖 返回目录 下一章 →