• 

　　 内部静态缓存大约 500MB

• 

　　 在高峰时间，总预测流量是 5000 个并发用户

• 

　　 每个用户的会话数据大约 500K

• 

　　 在高峰期间，总流量会话要求是 2.5GB。
　　正如你所看到的一样，在如此情况下，32 位 JVM 进程就无法满足。一个典型的

解决方案是进行流量拆分，在几个 JVM 进程或物理主机(假设有足够的硬件和 CPU core
可用)上。

　　大多数时候，业务流量将推动内存占用。除非你需要大量的数据缓存来实现适当

的性能，典型的门户应用网站(媒体)繁重的应用程序需求。数据缓存太多的时候应该用一
个黄色的标志标注一下，最好早点去重新审视一下一些设计元素。

　　4.量体裁衣
　　这一条，你应该做到：

• 

　　 理解基本的 JVM 原则和内存空间。

• 

　　 对所有应用程序有深入的了解及其它们的特点(大小、类型、动态流量、无状态

对象 VS 有状态对象、内部内存缓存等)。

• 

　　 对预测业务流量(并发用户)

—

给每一个应用程序能提出很好的观点 如果你需要

一个 64 位的虚拟内存，那么将设置哪个作为开始。

　　如果需要多个 JVM(中间件)过程。
　　等一下，这样做并不足够。虽然上面的信息是至关重要的，并且关于 Java 堆的

“

”

设置进行了 最佳猜测 ，对应用程序的行为进行模拟并且进行适当的分析、负载和性能测
试来验证 Java 堆内存要求。

　　推荐 Jprofiler 工具给大家，学习如何使用一个分析器的最好方法是正确理解应

用程序的内存占用。另一个方法是使用 Eclipse MAT 工具根据现有的环境进行堆转储分
析。堆转储非常强大，它可以允许你查看和理解 Java 堆的整个内存占用，包含类加载器
相关数据和在内存占用分析中必须要做的，特别是内存泄漏。

　　Java 分析器和堆转储分析工具允许你理解和验证应用程序内存足迹，包含内存

泄漏的检测和解决方案。负载测试和性能测试是必不可少的，通过模拟并发用户来验证早
期评估是否正确，它也会把应用程序瓶颈暴露出来并且允许你进行微调。推荐一个非常容
易上手的工具：Apache Jmeter。

　　最后将看一下这样的情况，应用程序在 Java EE 环境非常正常，直到有一天完

全正常的设备启动失败，例如硬件问题。突然的环境运行能力下降和整体环境下降，到底
发生了什么?

“

”

　　引起 多米诺效应 的原因有很多，但缺少 JVM 调优和处理故障转移的能力(短期

额外负荷)是很常见的。如果 JVM 进程运行在 80% + OldGen 空间容量和频繁的垃圾收
集,你如何预期故障转移场景?

　　前面模拟的负载和性能测试应该模拟这样的场景，调整你的调优设置使您的

Java 堆有足够的缓冲来处理额外的负载(额外的对象)在短期内。这主要适用于动态内存占
用，由于故障转移意味着将重定向一些固定的并发用户给可利用的 JVM 进程(中间件实
例)。

　　5.分而治之
　　这一条的前提是你已经完成了几十个负载测试。JVM 已经不存在泄露，你的应用

程序内存不能再进行任何减少。你已经尝试了几个调优策略，例如使用一个 64 位的 Java
堆空间在 10GB 以上。多个 GC 策略，尽管这样，仍然没有找到合适的可以接受的性能水
平?