在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应用程序中，内存管理必须是应用程序体系结构的核心部分。然而垃圾回收器对于那些未使用的对象是否被清理并不关心，所以开发人员还是需要适当的内存管理。此外，应用程序内存管理设计是应用程序配置的核心部分。