Java 内存泄漏

内存泄露是指应该被回收的内存没有被 GC 回收，轻则只会影响程序所占内存大小，严重可能导致 OutOfMemrory 异常。这类异常通常很难排查，大多数时候需要借助外部插件扫描内存判断。

常见的导致内存泄露的场景：

• 静态集合：如 hashMap，hashSet 等。静态集合类的声明周期和程序相同，集合中保存的所有对象元素永远不会被回收。除非手动将元素删除或是将静态集合置为 null

• 各种连接：数据库连接，I/O 连接等。编写代码时一定要注意关闭连接，这样 GC 才能回收到这部分内存

• 变量不合理的作用域：假如某对象只会在某一个方法中使用，建议将对象定义为局部变量，这样它就会随着方法的结束被回收，如果定义为全局变量，该变量的生命周期就会随对象的生命周期被回收，不会被回收

• 外部类持有内部类：如果一个外部类实例方法返回内部类对象，假如这个内部类实例被长期使用了，那么即使外部类往后没有用到，这部分内存也不会被回收

• 改变哈希值：对象存入哈希集合后，如果修改该对象影响哈希值的属性，那么原对象可能无法从集合中删除，如果不能找到并置空这部分内存，它的生命周期将随着集合被回收

• 集合赋值：假如通过常数变量记录集合元素个数，增加元素时增加常量并赋值，删除元素时直接减少常量，后续通过覆盖的方式修改新值。此时我们增加极多元素后又全部删除，这部分理应被回收的内存并不会被回收，因为集合本身还引用着它们，最好在删除元素时，手动将旧值置为空

• 缓存泄露：存放在集合中的元素很容易忘记回收，此时就建议使用 WeakHashMap，该哈希类在 key 只对本身有依赖的场景下会回收这部分内存

• 单例模式：单例类对象本身肯定是静态的，如果该对象包含其他对象的引用，那么这部分内存除非手动置为空，否则不会回收

• 监视器或回调：如果客户端在你实现的API中注册回调，却没有显示的取消，那么就会积聚。确保回调立即被当作垃圾回收的最佳方法是只保存他的弱引用，例如将他们保存成为WeakHashMap中的键

---

上面都是理论知识，下面笔者分享自己碰到的一次内存泄露：

场景介绍：系统采用扫描 Set 缓存的方法执行数据库操作，缓存中的数据有两种状态：完整和不完整。处理逻辑如下：

• 数据不完整且没入过库：执行 insert 操作
• 数据不完整并且已经入库：不进行任何操作
• 数据完整且没入过库：执行 insert 操作并删除缓存
• 数据完整且入过库：执行 update 操作并删除缓存

每个对象只会入库一条，完整入库后从缓存中删除。这里通过对象的多个属性拼装出唯一标识 key，通过该 key 确定对象是否已经入过库。只有成功入库的对象才会从集合中被删除，成功入库的条件是对象完整。

意外情况出现了，该对象唯一标识 Key 的多个属性中包含一个被加密的属性，其中该属性只在 Insert 入库操作时自动加密，加密后的结果会随着对象返回 Set 缓存。

内存泄露过程

系统扫描 Set 集合，扫到对象 A，假设此时它的唯一标识为：a-1-liming(加密属性)，因为对象不完整，执行入库操作后并没有从 Set 集合中删除。因为执行入库时配置的加密属性加密，它的唯一标识变成了 a-1-asdasdafafdasd(加密后的liming)，也就是说唯一标识和第一次对不上了。后面系统又扫到该对象，通过唯一标识判断还没有入过库（和第一次入库时的唯一标识已不相同），又执行入库操作，意外又发生了：这次是对 asdasdafafdasd 再加密，加密后更长了，超过了数据库配置的字段长度，入库失败了，缓存又被扔回 Set 集合，此时它的唯一标识变成了 a-1-asfddfhdfngldfnlkgnskdfgbkisjdbfgkdskjilubgikabv(asdasdafafdasd加密的结果)。后面系统又扫到这个缓存，又判断未入库，又执行 insert 操作，理所应当的又失败，又加密。。。。一直重复到该字段长度太长，java 堆内存被占满，再也无法回收下去，系统崩溃。

---

上面的过程真是一环套一环，最终跑崩了系统。这里笔者分享出来就是想告诉大家，绝大多数情况下我们碰到 OutOfMemory 异常都是系统存在重大漏洞，不会因为几个细节没注意，几个对象未回收就崩溃，但还是希望大家注意编码习惯，即时回收处理不用的内存。