使用类似 Memory Analyzer的工具生成并分析JVM heap dump快照。
#FormatImgID_11#
Java并发性
Java并发性可以定义为程序同时执行多个任务的能力。对于大型的Java EE系统，这意味着执行多个用户的业务功能的同时，实现最佳的吞吐量和性能的能力。
无论是硬件能力还是JVM稳定状况，Java并发性问题可能引起程序的瘫痪，严重影响程序的整体性能和可用性。
Thread Lock Contention
当您评估Java应用程序的并发线程的稳定状况时，你会经常遇到Thread lock contention的问题，这是目前最常见的Java并发问题。
例如：Thread lock contention会触发non-stop，它会尝试将一个缺少Java类(ClassNotFoundException的)加载到默认的JDK 1.7 ClassLoader。
如果您在成熟的技术环境中遇见像Thread Dump analysis这样的问题，我们强烈建议您积极面对它。这个问题的根源通常不同于之前的Java synchronization to legitimate IO blocking或者其他的non-thread safe calls。Lock contention问题往往是另一个问题的“症状”。
Java-level Deadlocks
真正的Java-level deadlocks是不太常见的，它同样可以极大程度地影响应用程序的性能和稳定性。当遇到两个或多个线程永远阻塞的时候，就会触发这样的问题。这种情况不同于其他常见的那种“day-to-day”线程问题，例如 lock contention、threads waiting alt="物联网" width="400" height="245" />
Oracle HotSpot 和IBM JVM为大多数的deadlock detectors情况提供了解决方案，帮助您快速找出造成这种状况的罪魁祸首的线程。遇到类似lock contention troubleshooting的问题，建议从诸如线程转储分析为出发点来解决该问题。
一旦找到造成问题的代码根源，解决方案涉及lock-ordering条件寻址和来自JDK其他可用的并发编程技术，如java.util.concurrent.locks.ReentrantLock，提供了诸如tryLock()的方法。这种方法给予开发人员更大的灵活性，也为防止deadlock和thread lock “starvation”提供了更多方式。
Clock Time和CPU Burn
在进行JVM调优的同时，也有必要检查应用程序的行为，更确切地说是最高clock time和CPU burn的贡献者。
当Java垃圾回收和线程并发不再是压力点，深入到你的应用程序代码的执行模式，并专注于顶级响应时间贡献者(也叫作clock time)是很重要的。检查应用程序代码的消CPU耗和Java 线程(CPU burn)也同样至关重要。CPU使用率较高(>75%)是不正常的(良好的物理资源的利用率)。因为这往往意味着效率低下和容量问题。对于大型的Java EE企业应用，保持安全的CPU缓冲区是必要的，以应对突发的负载冲击情况。
摒弃那些传统的跟踪方法，如在代码中加入响应时间“日志”。Java剖析工具和APM解决方案恰恰可以帮助您分析这类型的问题。这种方式更加高效、可靠。对于Java生产环境缺乏一个强大的APM解决方案。您仍然可以依赖诸如Java VisualVM的工具，通过多个快照进行thread dump分析，并使用OS CPU分析每个线程。
最后的建议是，不要妄图同时解决所有的问题。列出排在最前面的5个clock time和CPU burn问题，然后寻找解决方案。
Application预算
其他关于Java应用程序性能的重要方面是稳定性和可靠性。在有着99.9%典型可用目标的SLA umbrella下，稳定和可靠对于程序的操作尤为重要。这些系统应该具有高容错级别，并对应用和资源进行严格的预算，以防止发生多米诺效应。用这种方法可以防止一些这样的情况，例如，一个业务流程使用所有可用的物理，中间件或JVM资源。
Hot Spots
