随着时代的进步，越来越的新鲜便利的事情，代替原来的传统事物。在编程行业内也是如此。因此很多人都曾断言Java将被新一代便利的语言所代替，但是事实上，如今也有很多重要项目，Java仍然扮演着非常重要的角色。那么企业级Java最重要的应用性能有哪些？这里为大家总结了4个性能指标：业事务，外部服务，垃圾回收以及应用布局。下面是详细介绍。

　　1.商业事务

商业事务是真实用户体验的直观反映：它们抓取了用户与应用交互时，用户体验到的实时性能数据。测量商业事务的性能，需要抓取一件商业事务整体的响应时间及其各个组件的响应时间。这些响应时间再与满足业务需求的基准进行比较，从而决定应用是否正常。

如果你只打算测量应用的一个方面，本文会推荐你测量商业事务的表现。尽管容量指标能帮助你决定何时调节集群规模，但是商业事务才决定了应用本身的性能。你无需询问应用服务器线程池的使用情况，而是关心用户能否迅速完成他们的商业事务，以及这些事务的表现是否正常。

介绍一点背景知识：商业事务通过其入口进行辨别，即用户与你的业务进行互动的入口。这类互动包括：一个网页请求，一个网页服务调用，或消息队列中的一条消息。当然，你也可以基于一个URL参数为同样的网页请求定义多个入口，或基于一个服务调用的内容定义多个入口点。关键在于：商业交易必须与对你的业务流程相关联，比如说中国移动的空中缴费业务对应到系统中是多个原子服务，我们就应该将这几个原子服务通过相应的关联聚合成一个空中缴费业务来进行监控。

辨别某个商业交易后，它的性能就会在整个应用生态系统中进行测量。每个商业交易的性能会与其基准进行比较，判定其是否正常。譬如，如果某个商业事务的响应时间大于您设定的阈值，我们便判定其运行异常。

总而言之，商业事务最能反映用户体验，因此它们也是最重要的抓取维度。

　　2.外部服务

外部服务的形式多种多样：从属的网页服务、遗留系统或数据库等。外部服务是与应用交互的系统。运行在外部服务系统中的代码常常无法控制，但是我们可以控制这些系统的配置，因此了解他们是否运行正常以及何时出错也很重要。并且，我们必须有能力区分问题是出自自身应用，还是源于这些外部服务系统。

从商业事务的角度来说，我们可以辨别并测量这些处于自身应用的外部服务。有时，我们需要配置监控方法从而辨别那些包裹了外部服务调用的方法。但是对于常见的协议，诸如HTTP和JDBC，外部服务可以自动检测。

商业事务让你对应用的性能有了全局的掌控，帮助你对性能问题进行分类。但是外部服务总能以意想不到的方式极大地影响应用的运行，所以你必须监控它们。

　　3.垃圾回收

从Java发布最早版本开始，一直都保留的核心特性就是垃圾回收，它真是让人又爱又恨。垃圾回收使我们不再需要手动管理内存：当使用完一个对象后，我们只需删除它的引用，然后垃圾回收就会自动释放它。如果你使用过需要手动管理内存的语言，诸如C或C++，你会满怀感激。垃圾回收为程序员们减少了分配、释放内存空间的繁琐步骤。

此外，因为垃圾回收器会自动释放没有引用的内存空间，它减少了传统的内容泄露情况，即内存被分配后，该内存的引用在内存释放前就被删除了。听起来就像灵丹妙药，不是么？

尽管垃圾回收达成了无需手动管理内存的目标，也防止了传统的内存泄露，但是作为代价，垃圾回收过程有时相当笨拙。根据不同的JVM,垃圾回收策略也会不同。深入探讨这些策略超出了本文的主旨。但是，读者应该明白，了解垃圾回收期的工作原理，以及最佳的配置方案至关重要。

垃圾回收最大的敌人就是传说中的主要（major）或（full）垃圾回收。除了Azul JVM，所有的JVM都有这个问题。

　　4.应用布局

最后要探讨的性能指标是应用布局。因为云的出现，现在的应用变得更加灵活：应用环境可以根据用户需求调节大小。因此，对应用的布局进行检测从而决定实例的多少是否合适是非常重要的。如果你的实例太多，你的云主机成本就会增加。但如果你没有足够的实例，商业事务就会受到影响。

在评测过程中，下面两个指标尤其重要：

商业事务的吞吐量

容器性能

商业事务应该基准化，你应该知道在给定的时间里为了满足基准所需的实例数量。如果你的商业事务的吞吐量增长突然，你就要增加实例以满足用户。

另一个需要监测的是容器性能。具体来说，你想确定是否有应用中的实例负载过大，如果有，你或许想在那个应用中添加实例。从应用的角度查看实例状态很重要，因为单个实例可能由于垃圾回收之类的因素负载过大，但如果应用中大多数实例都负载过大，则该应用可能已经无法支持它接受的访问量。

因为应用中的实例可以单个地调节规模，所以分析各个实例的性能进而调整应用布局就至关重要。

企业级Java最重要的应用性能有哪些，通过上述介绍，相信大家已经清楚了吧，想了解更多关于企业级Java的信息，请继续关注中培伟业。