什么要素会影响Java EE的性能
什么因素会影响Java EE的性能
Java EE 是在 Java SE 的基础上构建的，它提供Web 服务、组件模型、管理和通信 API，可以用来实现企业级的面向服务体系结构（service-oriented architecture，SOA）和 Web 2.0应用程序。Java EE能够为我们帮助开发和部署可移植、健壮、可伸缩且安全的服务器端 Java应用程序。下面西安达内(www.xatarena.cn)的资深Java EE方向的老师为大家总结出了10点影响Java EE性能的几个问题，希望对学习Java语言的同学有所帮助。
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应用程序和中间件也是非常重要的。
5.缺乏适当的数据库SQL调优和容量规划
大家可能会对这一个感到惊奇：数据库问题。大多数Java EE企业系统是依赖关系型数据库处理复杂的业务流程。一个基础扎实稳固的数据库环境可以确保IT环境有规模的增长，来支持日益不断扩大的业务。
在实际中，与数据库相关的性能问题是很常见的。由于多数数据库事务处理都是由JDBC数据源执行的（包括关系持久化API，例如Hibernate）。而性能问题最初都会表现为线程阻塞。
6.特定应用程序性能问题
下面关注的是比较严重的Java EE应用程序问题。关于特定应用程序性能问题，总结了以下几个点：
线程安全的代码问题
通信API缺少超时设置
I/O、JDBC或者关系型API资源管理问题
缺乏适当的数据缓存
数据缓存过度
过多的日志记录
7.Java EE中间件调优问题
一般Java EE中间件都已经够用了，只是缺少必要的优化。大多数Java EE容器都能有多种方案供你的应用程序和业务进程选择。
如果没有进行适当的调整和实践，那么Java EE容器可能会处于一种消极的状态。
8.主动监控不足
缺乏监控，并不会带来实际性能问题，但它会影响你对Java EE平台性能和健康状况的了解。最终，这个环境可以达到一个破发点，这可能会暴露出一些缺陷和问题(JVM的内存泄漏，等等)。
9.公共基础设施硬件饱和
这个问题经常在有太多的Java EE中间件环境随着JVM进程被部署到现有硬件上面时看到。太多的JVM进程对有限的物理CPU核心来说是一个真正的程序性能杀手。另外，随着客户端业务的增长，硬件方面也需要再次考虑。
10.网络延迟
最后一个影响性能问题的是网络，网络问题时不时的都会发生，如路由器、交换机和DNS服务器失败。更常见的是在一个高度分散的IT环境中定期或间歇性延迟。下面图片中的例子是一个位于同一区域的Weblogic集群通信与Oracle数据库服务器之间的延迟。
Java EE 是在 Java SE 的基础上构建的，它提供Web 服务、组件模型、管理和通信 API，可以用来实现企业级的面向服务体系结构（service-oriented architecture，SOA）和 Web 2.0应用程序。Java EE能够为我们帮助开发和部署可移植、健壮、可伸缩且安全的服务器端 Java应用程序。下面西安达内(www.xatarena.cn)的资深Java EE方向的老师为大家总结出了10点影响Java EE性能的几个问题，希望对学习Java语言的同学有所帮助。
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应用程序和中间件也是非常重要的。
5.缺乏适当的数据库SQL调优和容量规划
大家可能会对这一个感到惊奇：数据库问题。大多数Java EE企业系统是依赖关系型数据库处理复杂的业务流程。一个基础扎实稳固的数据库环境可以确保IT环境有规模的增长，来支持日益不断扩大的业务。
在实际中，与数据库相关的性能问题是很常见的。由于多数数据库事务处理都是由JDBC数据源执行的（包括关系持久化API，例如Hibernate）。而性能问题最初都会表现为线程阻塞。
6.特定应用程序性能问题
下面关注的是比较严重的Java EE应用程序问题。关于特定应用程序性能问题，总结了以下几个点：
线程安全的代码问题
通信API缺少超时设置
I/O、JDBC或者关系型API资源管理问题
缺乏适当的数据缓存
数据缓存过度
过多的日志记录
7.Java EE中间件调优问题
一般Java EE中间件都已经够用了，只是缺少必要的优化。大多数Java EE容器都能有多种方案供你的应用程序和业务进程选择。
如果没有进行适当的调整和实践，那么Java EE容器可能会处于一种消极的状态。
8.主动监控不足
缺乏监控，并不会带来实际性能问题，但它会影响你对Java EE平台性能和健康状况的了解。最终，这个环境可以达到一个破发点，这可能会暴露出一些缺陷和问题(JVM的内存泄漏，等等)。
9.公共基础设施硬件饱和
这个问题经常在有太多的Java EE中间件环境随着JVM进程被部署到现有硬件上面时看到。太多的JVM进程对有限的物理CPU核心来说是一个真正的程序性能杀手。另外，随着客户端业务的增长，硬件方面也需要再次考虑。
10.网络延迟
最后一个影响性能问题的是网络，网络问题时不时的都会发生，如路由器、交换机和DNS服务器失败。更常见的是在一个高度分散的IT环境中定期或间歇性延迟。下面图片中的例子是一个位于同一区域的Weblogic集群通信与Oracle数据库服务器之间的延迟。