在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错误。