在Java中，内存泄露和其他内存相关问题在性能和可扩展性方面表现的最为突出。我们有充分的理由去详细地讨论他们。
Java内存模型——或者更确切的说垃圾回收器——已经解决了许多内存问题。然而同时，也带来了新的问题。特别是在有着大量并行用户的J2EE运行环境下，内存越来越成为一种至关重要的资源。乍看之下，这似乎有些奇怪，因为当前内存已经足够廉价，并且我们也有了64位的JVM和更先进的垃圾回收算法。
接下来，我们将会仔细的讨论一下关于Java内存的问题。这些问题可以分为四组：
在Java中，内存泄露一般都是由于引用对象不再被使用而造成的。当有多个引用的对象，同时这些对象又不再需要，然而开发者又忘记清理它们，这时极容易导致内存泄露的发生。
执行消耗太多的内存而导致不必要的高内存占用。这在为了用户体验而管理大量状态信息的 Web 应用中很常见。随着活跃用户数量的增加，内存很快到达了上限。未绑定或低效缓存配置是持续高内存占用的另一来源。
当用户负载增加时，低效的对象创建容易导致性能问题。从而垃圾回收器必须不断地清理堆内存。而这导致了垃圾回收器对CPU产生了不必要的高占用。随着CPU因垃圾回收而被阻塞，应用程序响应时间频繁的增加，导致其一直处于中等负载之下。这种行为也成为“GC trashing”。
低效的垃圾回收行为往往是由于垃圾回收器的缺失或者错误的配置。这些垃圾回收器将会时刻追踪对象是否被清理。然而这种行为如何以及何时发生必须由配置或者程序员，或者系统架构师决定的。通常，人们只是简单地“忘记”了正确的配置和优化垃圾回收器。我曾参加过一些关于“性能”的专题讨论会，发现一个简单的参数变化将会导致高达25%的性能提升。
在大多数情况下,内存问题不仅影响性能,还会影响可扩展性。每次请求消耗的内存数量越高,用户或Session可以执行的并行事务就越少。在某些情况下内存问题也影响可用性。当JVM耗尽了内存或者即将接近内存极限，这个时候它将退出并报OutOfMemory错误。这时经理会来到你的办公室，你就知道自己摊上大事了。
内存问题很难被解决通常有两个原因： 第一，某些情况下分析很复杂，也很困难，特别是如果你缺少正确的方法来解决他们；其次，他们通常是应用程序的架构基础。简单的代码更改不会帮助解决他们。
为了使开发过程更容易，我会展示一些实际应用中常被使用的反模式。这些模式已经能够在开发过程中避免内存问题。
HTTPSession作为缓存
此反模式是指滥用HTTPSession对象作为数据缓存。session对象的存在是为了存储信息，这个信息里面存在着一个HTTP请求。这也称为一个Session状态。这意味着，数据将被保存直至它们被处理。这些方法通常存在于一些重要的web应用程序中。web应用程序除了在服务器上存储这些信息外，没有别的方法。然而，一些信息是能够存储在cookie中，但是这将会带来一些其他的影响。
在cookie中，尽可能地保持少而短的数据，这是非常重要的。有时候很容易发生这种现象，session里存储着成兆字节的数据对象。这将会立即导致堆栈高占用和内存短缺。同时并行用户的数量非常有限,JVM将应对越来越多出现OutOfMemoryError错误的用户。多数用户Session也有其他性能损失。集群场景的session复制中，这将会增加序列化和沟通工作将导致额外的性能和可伸缩性问题。
在某些项目中这些问题的解决方案是增加数量的内存和切换到64位jvm。他们无法抵抗住仅仅增加几个G大小的堆栈内存的诱惑。然而，与其提供一个对真正问题的解决方案，不如隐藏这个现象。这个“解决方案”只是暂时的，同时还会引入了一个新的问题。越来越大的堆内存使它更难以找到“真正的”内存问题。对这种非常大的堆(大约6G)来说，大部分可用的分析工具是无法处理这些内存垃圾。我们在dynaTrace投入了大量的研发工作希望能够有效地分析大量的内存垃圾。随着这个问题变得越来越重要，一种新的JSR规范也提到了它。
由于应用程序架构尚未明确，导致Session缓存问题经常出现,。在开发过程中，数据被轻松而又简单的放入session当中。这是经常发生的，类似于一种“add and forget”方式，即没有人能够确保当这种数据不再需要时是被移除的。通常，当session超时时不需要的session数据应该被处理。在企业中，一些应用程序常常大量使用Session超时，这将会导致无法正常工作。此外经常使用非常高的Session超时- 24小时为用户提供额外的“体验”,使他们不必再次登录。
举一个实际的例子，从session里的数据库列表中选择所需要的数据。其目的是为了避免不必要的数据库查询。(是不是觉得有点过早优化呢？)。这将导致在session对象中为每个单独的用户放入几千个字节。虽然，缓存这些信息它是合理的，但用户session可以肯定是一个错误的地方。
另外一个例子是，为了管理Session状态而滥用Hibernate session。Hibernatesession对象只是为了快速访问数据库而放入HTTPsession对象中。然而，这将导致更多必要的数据被存储。同时每个用户的内存占用也将显著提高。
现如今，AJAX应用程序Session状态也可以在客户端进行管理。这使服务端程序变成无状态的，或接近无状态的，同时也显然有着更好的可扩展性。
线程本地变量内存泄露
在Java中使用ThreadLocal变量是为了在一个特定的线程中绑定变量。这意味着每个线程都有它自己的单独实例。这种方法一般在一个线程中用于处理状态信息，例如用户授权。然而，一个ThreadLocal变量的生命周期与另外一个线程的生命周期是息息相关的。被遗忘的ThreadLocal变量很容易导致内存问题，尤其是在应用服务器中。
如果忘记了设置ThreadLocal变量，尤其是在应用服务器中，这很容易导致内存问题。应用服务器利用线程池避免常量不断创建和线程销毁。举个例子，一个HTTPServletRequest类在运行时得到一个空闲的已分配的线程，在执行完后将它回传到线程池中。如果应用程序逻辑使用ThreadLocal变量和忘记了显式地移除它们，这时，内存是不会被释放的。
根据线程池大小——在程序系统中这些线程池可以是几百个线程。同时，由ThreadLocal变量引用的对象的大小，这可能导致一些问题。例如，在最坏的情况下，一个200个线程的线程池和一个5M大小的线程池将会导致1 GB的不必要的内存占用。这将立即导致强烈的垃圾回收反应，同时导致糟糕的响应时间和潜在的OutOfMemoryError错误。
一个实际的例子就是在JBossWS 1.2.0版本中出现的一个bug（在JBossWS1.2.1版本已经被修复）——“DOMUtils doesn’t clear thread locals”。此问题就是ThreadLocal变量导致的，它引用了一个14MB的解析文档。
大型临时对象
大型临时对象在最坏的情况下也能导致outofmemoryerror错误或者至少强烈的GC反应。例如，如果非常大的文档(XML、PDF、图片…)必须阅读和处理时。在一个特定的情况下，应用程序几分钟都没有响应或性能非常有限,几乎没有可用的。其中根本原因是垃圾回收反应过于强烈。下面对读取PDF文档的一段代码作了详细分析：
byte tmpData[] = new byte [1024];int offs = 0;do{int readLen = bis.read (tmpData, offs, tmpData.length - offs);if (readLen == -1)break;
offs+= readLen;if (oofs == tmpData.length){byte newres[] = new byte[tmpData.length + 1024];
System.arraycopy(tmpData, 0, newres, 0, tmpData.length);
tmpData = newres;
}
} while (true);这些文档采用按固定字节数的方式来读取。首先，他们被读入中字节数组中，然后发送到用户的浏览器中。然而仅仅几个并行请求将会导致堆溢出。由于读取文档采用了极其低效的算法，这将导致问题越来越糟糕。最初的想法只是创建1KB的初始字节数组。如果这个数组满了，则一个新的1KB数组将被创建，同时这个老的数组将拷贝到新的数组中。这意味着当读取文档时，一个新数组将被创建，同时将读取的每字节都复制到新数组中。这将导致大量的临时对象和两倍于实际数据大小的内存消耗——数据将永久被复制。
在处理大量数据时,优化处理逻辑性能是至关重要的。在这种情况下,一个简单的负载测试会显示这一问题。
糟糕的垃圾回收器配置
到目前为止，在所提到的情境中出现的问题基本都是由应用程序代码所导致的。然而，这些原因的根源是由于垃圾回收器配置错误，或者丢失。我常常看到用户相信他们的应用程序服务器的默认设置，同时也相信应用服务器的开发者了解哪些是自己的程序最好的。无论如何，堆的配置很大程度上取决于应用程序和实际使用场景。根据场景来调整参数，应用程序才能更好地执行。和一批执行长期任务的应用程序相比，一个执行大量短而持久的应用程序配置起来是完全不同的。此外，实际的配置还取决于JVM使用情况。对IBM来说，什么才能使Sun Jvm正常运行可能是一场噩梦(或至少是不理想的)。配置错误的垃圾收集器通常不会立即被确认为性能问题的根源(除非你监控了垃圾收集器的活动)。通常我们肉眼可见的问题都是响应过慢。同时，理解垃圾回收活动与响应时间的关系也是不明显的。如果垃圾回收的时间与响应时间没什么关联，人们通常会发现一个非常复杂的性能问题。响应时间和执行时间度量问题主要体现在应用程序——对于这种现象，在不同的地方都没有一个明显的模式。
下图显示了事务指标与垃圾收集时间在dynaTrace中的关系。我发现了一些情况，关于垃圾回收器的优化问题。人们正打算花几周的时间去解决如何在几分钟内设置解决性能问题。
类加载器内存泄露
在谈到内存泄漏时，大部分人主要认为是堆中的对象。除了对象，类和常量也是托管在堆中。根据JVM，它们被放入堆中特定的区域。例如Sun JVM使用所谓的永久代或PermGen。通常情况下，类被放入堆中好几次。仅仅是因为他们已经被不同的类加载器加载。在现代化企业级应用程序中，加载类的内存占用能够达到几百MB。
关键是避免无谓地增加类的大小。一个很好的例子是大量字符串常量的定义——例如在GUI应用程序中。这里所有的文本通常存储在常量。而使用常量字符串的方法原则上是一个好的设计方法，内存消耗不应该被忽视。在真实的情况下，在一个国际化应用程序中，所有常量都会被定义为各种语言。一个很不起眼的代码错误都会影响到已经被加载的类。最终的结果是，在应用程序的永久代中，JVM将出现OutOfMemoryError 错误，同时崩溃。
应用服务器还面临着类加载器泄漏的问题。这些泄漏的原因主要是因为类加载器不能被垃圾回收，因为类加载器中的类的一个对象仍然活着。结果，这些类并不打算释放这些内存占用。而现在，这个问题已经被J2EE 应用程序服务器很好的解决了，它似乎更常出现在OSGI-based应用程序环境。
总结
在Java应用程序中内存问题通常是多方面的，这容易导致性能和可扩展性的问题。特别是在有着大量并行用户的J2EE应用程序中，内存管理必须是应用程序体系结构的核心部分。然而垃圾回收器对于那些未使用的对象是否被清理并不关心，所以开发人员还是需要适当的内存管理。此外，应用程序内存管理设计是应用程序配置的核心部分。
你的经验
这些都是我在现实世界应用程序中发现的反模式。如果你有额外的反模式或共同的问题，我很愿意更多地了解他们。
关于作者
这篇文章基于我和codecentric的作者Mirko Novakovic共同研究的性能反模式系列。
其他感兴趣的博客
由于性能反模式是我的爱好，我将定期发布关于反模式的帖子。它们将会从这些帖子里选择你们可能感兴趣的一篇帖子。
如果你想要了解更多关于如何解决像本文中提到的内存问题，和其他一些java运行坏境相关的问题，你也许对我同事最近一本关于持续应用程序性能管理的白皮书感兴趣。
随时随地看视频
