【译文-JBoss】Why JBoss AS 7 is so fast

Why JBoss AS 7 is so fast

为什么 JBoss AS 7 这么快

by Jason Greene 2011-7-25
原文地址

The short answer is that it is designed around Ahmdahl’s law (effective parallelization of work) as opposed to Moore’s law (waiting for hardware with a faster clock rate). Almost every CPU powering desktops, laptops, and servers is now at least dual core, and the trend is rapidly expanding. The days of the frequency race are essentially over. So, now software must adapt to tap into the power of the hardware of today and tomorrow.

简短的答案就是因为JBoss AS 7是依据Ahmdahl法则（阿姆达尔法则，高效并行计算）设计的，而不是依据摩尔定律（等待硬件拥有更快的时钟频率）。在现在，几乎每台台式机、笔记本和服务器（现在得加上手机。。。）都至少是双核CPU，并且多核趋势还在飞速发展，从本质上来说，依靠时钟频率的时代已经终结了，在现在以及未来，新型的软件开发必须适应于依赖于硬件的计算能力。

JBoss AS underwent an aggressive transformation to achieve this critical evolution. With AS 7 we started from scratch and built an entirely new, highly performant, and manageable core architecture from the ground up. With some truly amazing engineering effort we were able to go from a tiny prototype on github, to the full blown Java EE Web Profile compliant container of today in a little over a year (not to mention that during all of this we also delivered AS 6 which allowed JBoss users early access EE6 technology).

为了这一关键的演进，JBoss AS进行了一场重大的变革。我们重写了AS7，并且建立了一个全新的、高性能的、可管理的核心框架。在令人惊异的工程师的努力下，我们从github上的一个小小原型，在一年多时间里发展成为了完全成熟的符合Java EE Web Profile标准的服务器（更不要说在这一年里我们还发布了Java AS 6，这样可以让JBoss的用户更早地尝试Java EE 6的新特性）。

Before explaining, allow me to provide some background. The core problem an application server is tasked with is managing services. Nearly all components in a modern application have some kind of life-cycle, meaning that there is some point at which it must be started, and some later point at which it must be stopped. We label anything that has a life-cycle a service. Another important property of a service is that they typically have relationships that impact their respective life-cycles.

在开始解释之前，请允许我先给出一些相关的背景知识。应用服务器要解决的一个核心问题就是管理服务。现代服务器里几乎所有的组件都有生命周期，意味着这些组件会在某个点要开始运行，又会在某个点停止。我们将所有具有具有生命周期的事物都看做一个服务（service）。服务的另一个特性就是服务与服务之间的依赖关系会影响到它们自己的生命周期。

As an example, we might say that a servlet’s service depends on a web server. In addition we would probably say that if that servlet uses some other resource like a database connection or an EJB that it depends on those being being available as well. When an application server starts or deploys it must make sure that it starts all of the various services in the correct order. Further if any of these services are somehow stopped, it must stop all dependents first (essentially reverse order). This is a fairly simple problem when this is done in a single thread.JBoss AS 7 on the other hand starts and deploys all services in parallel.

举一个例子，Servlet的服务依赖于web server，另外，Servlet还有可能使用了其他的资源，比如数据库连接、EJB等等。Servlet的可用性依赖于这些资源的可用性。当应用服务器启动或者部署这个Servlet时，它必须保证所有的这些资源以一种正确的顺序启动。更近一步，如果这些服务中的某一个因为不知名的原因停止了，应用服务器必须保证所有依赖于此服务的服务能在第一时间停止（以相反顺序）。在单线程环境下这是一个简单的问题。但JBoss AS 7 事实上却是以并行形式来启动和部署所有服务的

This complex problem is solved by our new service container, the JBoss Modular Service Container. MSC is essentially an advanced concurrent state machine.

这个复杂问题被我们的新服务容器解决了 —— JBoss模块化服务容器。 MSC事实上是一个高级的并行状态机。

It analyzes the dependencies between all services on the fly and attempts to start as many as it can at the same time, while still adhering to the relationship requirements. This means that not only is startup blazing fast, but you also now can deploy multiple deployments in parallel.

MSC在运行中分析服务的依赖关系，并且会争取在同一时间启动更多的服务，同时满足这些服务的关系需求。这意味着不仅可以更快速的启动JBoss，而且可以使我们进行并行部署。

In addition to parallel services, JBoss AS 7 also has modularity and concurrent class loading. By segmenting classes into proper modules, the app server can naturally optimize access patterns, and only look in the spot that truly owns the classes. Also, since the visibility between modules is intentionally limited, searching is cheap. In the case of JBoss Modules, module resolution and class lookup are O(1). All of this has a very high degree of concurrency, even a significant portion of class definition.

除了并行服务之外，JBoss AS 7还有类模块化和并行类加载技术。通过将类分割给适当的模块，应用服务器可以自然地优化访问模式，并且可以只通过查找一个点就获得所需要的类。另外，由于故意限制了模块之间的可见性，查找的开销是很小的。对于JBoss Modules，模块解析和类查找的时间复杂度均是O(1)。所有的这些操作都有一个很高的并行度，甚至大部分的类定义也是并行的。

Deployment processing is also very efficient. One major optimization is that we index annotation information by quickly scanning a subset of the class file data. For even greater efficiency we allow modules the ability to pregenerate a space efficient index which is designed to be loaded very quickly. Yet another deployment optimization is that we carefully cache and reuse reflection data, since the JVM is not very efficient at doing so.

JBoss AS 7对部署的处理也非常高效。一个主要的优化是我们通过快速扫描部分类文件来对注释信息进行索引。为了更高效，我们允许模块事先生成空间效率指数来实现更快的加载。另一个部署上的优化是我们谨慎地使用了缓冲区和重用reflection data，因为JVM在这方面不是很有效率。

Finally the last major reason I wanted to highlight is that we have and will continue to be very militant about our CPU and memory usage on the start and deploy path. This is all about making good choices starting at the design phase. An interesting example is our moratorium on using JAXB (or any other introspection driven binder) to parse configuration that is only read once. It ends up spending the same or more time figuring out how to parse than it does doing the actual parsing. This adds up. In fact, just the XML processing in AS 5 and 6 took longer than the entire 7 boot time.

最后一个我想重点强调的重要原因就是我们在启动和部署上会继续优化CPU和内存使用率。这就是在设计阶段就做出来的好决定。一个有趣的例子是我们不再使用JAXB（或者其他内省机制驱动的绑定器）来解析只读一次的配置文件。JAXB或其他内省机制驱动的绑定器会花费和实际解析工作一样长或甚至更长的解析时间。这就意味着，实际上AS5和AS6解析XML的时间会比AS7的启动时间还要长。

Hopefully this provides a better picture as to how we made the efficiency gains, and why some things are very different in 7 than in the past. This, however, is just the beginning. Stay tuned for my next blog which will talk about the overall 7 roadmap.

希望上述文章能给你提供关于我们是如何做到高效以及为什么AS7与以前的版本有很大不同的清晰图景。然而，这仅仅只是一个开始。下一篇博客，我将会讨论AS7的roadmap。