如果你想要生成错误的键值对可以像下面这样做
class BadKey {
// no hashCode or equals();
public final String key;
public BadKey(String key) { this.key key; }
}
Map map System.getProperties();
map.put(new BadKey("key"), "value"); // Memory leak even if your threads die.
A4除了被遗忘的监听器静态引用hashmap中key错误/被修改或者线程阻塞不能结束生命周期等典型内存泄露场景下面介绍一些不太明显的Java发生内存泄露的情况主要是线程相关的。
Runtime.addShutdownHook后没有移除即使使用了removeShutdownHook由于ThreadGroup类对于未启动线程的bug它可能不被回收导致ThreadGroup发生内存泄露。
创建但未启动线程与上面的情形相同
创建继承了ContextClassLoader和AccessControlContext的线程ThreadGroup和InheritedThreadLocal的使用所有这些引用都是潜在的泄露以及所有被类加载器加载的类和所有静态引用等等。这对ThreadFactory接口作为重要组成元素整个j.u.c.Executor框架(java.util.concurrent)的影响非常明显很多开发人员没有注意到它潜在的危险。而且很多库都会按照请求启动线程。
ThreadLocal缓存很多情况下不是好的做法。有很多基于ThreadLocal的简单缓存的实现但是如果线程在它的期望生命周期外继续运行ContextClassLoader将发生泄露。除非真正必要不要使用ThreadLocal缓存。
当ThreadGroup自身没有线程但是仍然有子线程组时调用ThreadGroup.destroy()。发生内存泄露将导致该线程组不能从它的父线程组移除不能枚举子线程组。
使用WeakHashMapvalue直接(间接)引用key这是个很难发现的情形。这也适用于继承Weak/SoftReference的类可能持有对被保护对象的强引用。
使用http(s)协议的java.net.URL下载资源。KeepAliveCache在系统ThreadGroup创建新线程导致当前线程的上下文类加载器内存泄露。没有存活线程时线程在第一次请求时创建所以很有可能发生泄露。(在Java7中已经修正了创建线程的代码合理地移除了上下文类加载器。)
使用InflaterInputStream在构造函数(比如PNGImageDecoder)中传递new java.util.zip.Inflater()不调用inflater的end()。仅仅是new的话非常安全但如果自己创建该类作为构造函数参数时调用流的close()不能关闭inflater可能发生内存泄露。这并不是真正的内存泄露因为它会被finalizer释放。但这消耗了很多native内存导致linux的oom_killer杀掉进程。所以这给我们的教训是尽可能早地释放native资源。
java.util.zip.Deflater也一样它的情况更加严重。好的地方可能是很少用到Deflater。如果自己创建了Deflater或者Inflater记住必须调用end()。
22/2<12