你们好，最近小未来发现有诸多的小伙伴们对于javaee和javase有啥区别，java ee这个问题都颇为感兴趣的，今天小活为大家梳理了下，一起往下看看吧。

1、 容量规划是一个全面的、不断发展的过程标准，它预测当前和未来的IT环境容量需求。制定合理的产能计划，不仅可以保证和跟踪当前的IT生产能力和稳定性，还可以保证新项目以最小的风险部署到现有的生产环境中。

2、 硬件、中间件、JVM、调整等。应在项目部署前准备好。

3、 “没有规则，就没有方圆”。第二个常见原因是Java EE中间件或基础设施没有标准化。项目初期，新平台上没有合理的规范，导致系统稳定性差。这将增加客户成本，

4、 因此，有必要花时间制定一个合理的Java EE中间件环境规范。这项工作应该与初始容量规划迭代相结合。

5、 你熟悉错误信息“java.lang.OutOfMemoryError”吗？由于内存消耗过多(Java堆、本机堆等)而引发的异常。)的JVM。

6、 垃圾收集的问题不一定表现为OOM状态。过量的垃圾收集可以理解为JVM GC线程在短时间内轻微或过量收集收集数据导致的JVM暂停时间过长和性能下降。可能有几个原因：

7、 与JVM的负载和应用程序的内存使用相比，Java堆可能选得太小。

8、 JVM GC策略的不合理使用。

9、 应用程序的静态或动态内存使用量太大，无法在32位JVM上使用。

10、 随着时间的推移，JVM OldGen的泄漏越来越严重，几个小时或者几天后GC才发现。

11、 JVM PermGen空间(仅限HotSpot VM)或native heap会随着时间的推移而泄露，这是一个非常普遍的问题；OOM的错误往往是观察一段时间后，应用动态调整。

12、 YoungGen和OldGen之间的比例空间与您的应用程序不匹配。

13、 32位虚拟机上的Java堆太大，导致本机堆溢出，这可以通过OOM尝试链接新的Java EE应用程序、创建新的Java线程或计算本地内存分配任务来表现。

14、 建议：

15、 观察并深刻理解JVM垃圾收集。启动GC，根据健康合理的评估提供所有数据。

16、 记住，GC相关的问题不会在开发或功能测试时被发现，而需要在多用户、高负载的测试环境中被发现。

17、 Java EE性能差的第四个原因是高度分布式系统，典型案例是电信IT环境。在这种环境下，一个中间件领域(比如服务总线)很少做所有的工作，而只是把一些业务“委托”给其他部分，比如产品质量，

18、 客户资料和订单管理，到其他Java EE中间件平台或遗留系统中，如支持各种不同的负载类型和通信协议的大型机。

19、 这样的外部系统调用意味着客户端的Java EE应用程序触发创建或重用套接字链接从外部系统中读写数据。根据业务流程的实施和实现可以配置成同步调用或异步调用。需要注意的是，

20、 响应时间会根据外部系统的稳定状况进行改变，所以通过适当的使用超时来保护Java EE应用程序和中间件也是非常重要的。

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

22、 同步和相继调用太多的外部系统。

23、 在Java EE客户端应用程序和外部系统之间链接超时，使数据丢失或者值太高导致客户端线程被卡住，从而导致多米拉效应。

24、 超时，但程序仍正常执行，可是中间件不处理这种奇怪的路径。

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

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

27、 在实际中，与数据库相关的性能问题是很常见的。由于多数数据库事务处理都是由JDBC数据源执行的（包括关系持久化API，例如Hibernate）。而性能问题最初都会表现为线程阻塞。

28、 以下是我在10年的工作中，经常出现的关于数据库方面的问题（以Oracle数据库为例）：

29、 孤立的，长时间运行的SQL。主要表现为线程阻塞、SQL没有进行优化、缺少索引、非最佳的执行计划、返回大量数据集等等。

30、 表或行级数据锁定。当提交一个双阶段事务模型时（例如，臭名昭著的Oracle可疑事务）。Java EE容器可能会留下一些未处理的事务等待最后的提交或回滚，留下的数据锁能触发性能问题，直到最后的锁被移除。

31、 例如中间件断电或者服务器崩溃都可能引起这些情况发生。

32、 缺乏合理规范的数据库管理工具。例如Oracle里面的REDO logs，数据库数据文件等。磁盘空间不足，日志文件不旋转等都会触发较大的性能问题和断电情况。

33、 建议：

34、 合理的容量规划，包括负载和性能测试都是必不可少的，优化数据环境和及时发现问题。

35、 如果是使用Oracle数据库，确保DBA团队定期审查AWR报告，尤其是在上下关联的事件和根源分析过程中。

36、 使用JVM线程存储和AWR报告查明SQL运行缓慢的原因或者使用监控工具来做。

37、 加强“操作”方面的数据库环境（磁盘空间、数据文件、重做日志、表空间等）以适当的监视和报警。如果不这么做，会让客户端IT环境出现较多的断电情况和花许多时间进行故障调修。

38、 下面关注的是比较严重的Java EE应用程序问题。关于特定应用程序性能问题，总结了以下几个点：

39、 线程安全的代码问题

40、 通信API缺少超时设置

41、 I/O、JDBC或者关系型API资源管理问题

42、 缺乏适当的数据缓存

43、 数据缓存过度

44、 过多的日志记录

45、 一般Java EE中间件都已经够用了，只是缺少必要的优化。大多数Java EE容器都能有多种方案供你的应用程序和业务进程选择。

46、 如果没有进行适当的调整和实践，那么Java EE容器可能会处于一种消极的状态。

47、 主动监控不足

48、 缺乏监控，并不会带来实际性能问题，但它会影响你对Java EE平台性能和健康状况的了解。最终，这个环境可以达到一个破发点，这可能会暴露出一些缺陷和问题(JVM的内存泄漏，等等)。

49、 以我的经验来看，如果一开始不进行监控，而是运行几个月或者几年后再进行，平台稳定性将大打折扣。

50、 也就是说，改善现有的环境永远都不会晚。下面是一些建议：

51、 复查现有Java EE环境监测能力和找到需改进的地方。

52、 监测方案应该尽可能的覆盖整个环境。

53、 监控方案应该符合容量规划进程。

54、 这个问题经常在有太多的Java EE中间件环境随着JVM进程被部署到现有硬件上面时看到。太多的JVM进程对有限的物理CPU核心来说是一个真正的程序性能杀手。另外，随着客户端业务的增长，

55、 硬件方面也需要再次考虑。

56、 网络延迟

57、 最后一个影响性能问题的是网络，网络问题时不时的都会发生，如路由器、交换机和DNS服务器失败。更常见的是在一个高度分散的IT环境中定期或间歇性延迟。

58、 下面图片中的例子是一个位于同一区域的Weblogic集群通信与Oracle数据库服务器之间的延迟。

59、 间歇或定期的延迟会触发一些重要的性能问题，以不同的方式影响Java EE应用程序。

60、 因为大量的fetch迭代（网络传入和传出），涉及大数据集的数据查询问题的应用会非常受网络延迟的影响

61、 应用程序在处理外部系统大数据负载（例如XML数据）时也会很受网络延迟的影响，会在发送和接收响应时产生巨大的响应间隔。

62、 Java EE容器复制过程（集群）也会受到影响，并且会让故障转移功能（如多播或单播数据包损失）处于风险中。

63、 JDBC行数据“预取”、XML数据压缩和数据缓存可以减少网络延迟。在设计一个新的网络拓扑时，应该仔细检查这种网络延迟问题。

以上就是java ee这篇文章的一些介绍，希望对大家有所帮助。