在32-bit或64-bit JVM之间进行明智的选择。如果程序运行需要超过2GB内存，并且JVM暂停时间在可接受范围内，可以考虑使用64-bit JVM。
永远将应用程序放在第一考虑。确保将其配置好，并根据程序的内存占用量调整heap尺寸。建议通过性能和负载测试来衡量实时数据占有量。
larger heap并不总是表现得更好、更快，因此不需要过度调整Java heap。并行中的JVM性能调优，找准机会减少或“spread”程序的内存占有量，以保证JVM的平均响应时间<1%。
对于32-bit JVM，为了从元数据和本地heap中留出一些内存，考虑2GB的最大heap尺寸。
对于64-bit JVM，我们要想办法在垂直和水平层面进行扩展，而不是试图将Java heap尺寸增加到15GB以上。这种做法往往提供更好的吞吐量，更好地利用硬件，提高应用程序的故障切换功能。
不许重复开发：充分利用开源以及商业故障排除的优势和监控工具，使这些变成可能。APM(应用性能管理)产品在过去十年里发展迅猛。
JDK 1.8 Metaspace指南
目标建议内存大小GC调整
监控和故障排除
默认情况下，元空间内存空间是无界的，并使用可用于动态扩展的process或OS native memory。内存空间分成快并通过mmap被JVM进行存储。我们建议保持默认设置，以动态调整模式为出发点，将简化的尺寸与密切监测的应用程序元数据占有量相结合，从而进行更好的容量规划。新增一个JVM选项(-XX:MaxMetaspaceSize=<NNN>)，可以让您限制分配给class metadata的本地内存。当面临物理资源（RAM）紧张或类似于内存泄露的情况时，建议将它作为一个保障机制。
对那种具有larger class metadata footprint或dynamic classloading的Java应用程序，我们建议通过新的JVM选项调整初始元空间大小 ：-XX:MetaspaceSize=<NNN>，例如：1GB。这种调整方法将有助于避免包括class metadata在内的早期垃圾回收，尤其是在Java应用程序的 “warm-up”期。
Hot Spots
故障诊断和监视
目标建议测量和监视应用程序YoungGen和OldGen内存占用，包括GC活动。为您的应用程序决定正确的GC策略和Java堆大小。
调整应用程序的内存占用量，如live对象。
分析、监控您所使用的Java分析工具，如JProfiler、Java VisualVM或其他商业APM产品。允许通过–verbose:gc记录JVM GC活动。您也可以使用类似GCMV（GC Memory Visualizer）的工具查看JVM的暂停时间和内存分配率。
性能提示：过多的内存分配率可能意味着需要进行垂直和横向扩展，或从多个JVM进程中分离出实时数据。
为了long-lived对象或long-term实时数据考虑，可以生成并分析JVM heap dump快照。Heap dump分析对于程序内存占用(retention)的优化是非常有帮助的。
性能提示：由于从32位到64位，Java应用程序对heap 的需求会比原来高1.5倍。所以，在Java 1.7及以下的版本(这是默认的)中使用 -XX:+UseCompressedOops是非常重要的。这样的参数调整大大减轻了64位JVM的性能压力。
调查OutOfMemoryError 问题，寻找OldGen内存泄露的根源。使用类似Java VisualVM、Plumbr的工具（Java内存泄漏检测器），分析可能存在的内容泄露。性能提示：要着重分析最大的Java对象上。要意识到降低内存占有量就意味着提升性能，并降低GC活动。
#FormatImgID_10#