????本文作者是一名有 10 多年经验的高级系统架构师，他的主要专业领域是 Java EE、中间件和 JVM 技术。他在性能优化和提升方面也有很深刻的见解，下面他将和大家分享一下常见的 10 个影响 Java EE 性能问题。

????????1. 缺乏正确的容量规划

????????容量规划是一个全面的和发展的过程标准，预测当前和未来的 IT 环境容量需求。制定合理的容量规划不仅会确保和跟踪当前 IT 生产能力和稳定性，同时也会确保新项目以最小的风险部署到现有的生产环境中。硬件、中间件、JVM、调整等在项目部署之前就应该准备好。

????????2. Java EE 中间件环境规范不足

????????“没有规矩，不成方圆”。第二个比较普遍的原因是 Java EE 中间件或者基础架构不规范。在项目初始，新平台上面没有制定合理的规范，导致系统稳定性差。这会增加客户成本，所以花时间去制定合理的 Java EE 中间件环境规范是必须的。这项工作应与初始容量规划迭代相结合。

????????3. Java 虚拟机垃圾回收过度

????????各位对“java.lang.OutOfMemoryError”这个错误信息是不是很熟悉呢？由于 JVM 的内存空间过度消耗（Java 堆、本机堆等）而抛出的异常。

????????垃圾收集问题并不一定会表现为一个 OOM 条件，过度的垃圾收集可以理解成是 JVM GC 线程在短时间里进行轻微或超量收集集合数据而导致的 JVM 暂停时间很长和性能下降。可能有以下几个原因：

• 与 JVM 的负载量和应用程序内存占用量相比，Java 堆可能选择的太小。
• JVM GC 策略使用不合理。
• 应用程序静态或动态内存占用量太大，不适合在 32 位 JVM 上使用。
• JVM OldGen 随着时间推移，泄漏越来越严重，而 GC 在几个小时或者几天后才发现。
• JVM PermGen 空间(只有 HotSpot VM）或本机堆随着时间推移会泄露是一个非常普遍的问题；OOM 的错误往往是观察一段时间后，应用程序进行动态调动。
• YoungGen 和 OldGen 的比例空间与你的应用程序不匹配。
• Java 堆在 32 位的 VM 上太大，导致本机堆溢出，具体可以表现为 OOM 试着去链接一个新的 Java EE 应用程序、创建一个新的 Java 线程或者需要计算本地内存分配任务。

????????建议：

• 观察和深入理解 JVM 垃圾回收。启动 GC，根据健康合理的评估来提供所有的数据。
• 记住，GC 方面的相关问题不会在开发中或者功能测试时发现，它需要在多用户高负载的测试环境下发现。

????????4. 与外部系统集成过多或过少

????????导致 Java EE 性能差的第四个原因是高分布式系统，典型案例是电信 IT 环境。在这个环境中，一个中间件领域（例如，服务总线）很少会做所有的工作，而仅仅是把一些业务“委托”给其他部分，例如产品质量，客户资料和订单管理， 到其他 Java EE 中间件平台或遗留系统中，如支持各种不同的负载类型和通信协议的大型机。

????????这样的外部系统调用意味着客户端的 Java EE 应用程序触发创建或重用套接字链接从外部系统中读写数据。根据业务流程的实施和实现可以配置成同步调用或异步调用。需要注意的是，响应时间会根据外部系统 的稳定状况进行改变，所以通过适当的使用超时来保护 Java EE 应用程序和中间件也是非常重要的。

????????下面这 3 种情况是经常出现问题和性能降低的地方：

• 同步和相继调用太多的外部系统。
• 在 Java EE 客户端应用程序和外部系统之间链接超时，使数据丢失或者值太高导致客户端线程被卡住，从而导致多米拉效应。
• 超时，但程序仍正常执行，可是中间件不处理这种奇怪的路径。

????????最后，建议多进行负面测试，这意味着需要“人为”创造产生这些问题的条件，用来测试应用程序和中间件之间是如何处理外部系统错误。

????????5. 缺乏适当的数据库 SQL 调优和容量规划

????????大家可能会对这一个感到惊奇：数据库问题。大多数 Java EE 企业系统是依赖关系型数据库处理复杂的业务流程。一个基础扎实稳固的数据库环境可以确保 IT 环境有规模的增长，来支持日益不断扩大的业务。