简短的答案是，它是围绕Ahmdahl定律（有效并行化工作）设计的，而不是Moore定律（等待具有更快时钟速率的硬件）。现在几乎所有为台式机、笔记本电脑和服务器供电的CPU至少是双核的，这种趋势正在迅速扩大。频率竞赛的时代基本上已经结束。因此，现在软件必须适应，以利用今天和明天的硬件力量。
JBoss AS经历了激进的转型，以实现这一关键演变。在AS 7中，我们从零开始，从头开始构建了一个全新的、高性能的、可管理的核心架构。通过真正的惊人工程努力，我们能够在一年多一点的时间里从github上的一个小型原型发展到今天的完全Java EE Web Profile兼容的容器（不用说，在这个过程中我们还发布了AS 6，允许JBoss用户提前访问EE6技术）。
在解释之前，让我提供一些背景信息。应用服务器需要解决的核心问题是管理服务。现代应用中的几乎所有组件都有某种生命周期，这意味着它在某个时刻必须启动，在稍后的某个时刻必须停止。我们称任何有生命周期的东西为服务。服务的另一个重要特性是，它们通常有影响其各自生命周期的关系。例如，我们可以说servlet的服务依赖于一个web服务器。此外，我们可能还会说，如果该servlet使用某些其他资源，如数据库连接或EJB，它也依赖于这些资源的可用性。当应用服务器启动或部署时，它必须确保以正确的顺序启动所有各种服务。进一步说，如果其中任何一个服务以某种方式停止，它必须首先停止所有依赖项（本质上按相反顺序）。当这一切都在单个线程中完成时，这是一个相当简单的问题。
另一方面，JBoss AS 7会并行启动和部署所有服务。这个复杂的问题通过我们的新服务容器，JBoss模块化服务容器（MSC）得到解决。MSC本质上是一个高级并发状态机。它会实时分析所有服务之间的依赖关系，并尽可能同时启动尽可能多的服务，同时仍然遵守关系要求。这意味着不仅启动速度非常快，现在您还可以并行部署多个部署。
除了并行服务外，JBoss AS 7还具有模块化和并发类加载。通过将类分段到适当的模块中，应用服务器可以自然地优化访问模式，并且只查找真正拥有这些类的位置。此外，由于模块之间的可见性有意限制，搜索成本很低。在JBoss模块的情况下，模块解析和类查找是O(1)。所有这些都具有非常高的并发度，甚至包括大量的类定义。
部署处理也非常高效。一个主要的优化是我们通过快速扫描类文件数据的子集来索引注解信息。为了进一步提高效率，我们允许模块预先生成一个空间高效的索引，该索引设计得可以非常快速地加载。另一个部署优化是我们仔细缓存和重用反射数据，因为JVM在这样做方面效率不高。
最后，我想重点强调的最后一点是我们对启动和部署路径上的CPU和内存使用非常严格。这始于设计阶段的选择。一个有趣的例子是我们禁止使用JAXB（或任何其他基于反射的绑定器）来解析只读取一次的配置。结果是，解析配置所花费的时间和实际解析所花费的时间相同甚至更多。这累积起来。实际上，AS 5和6中的XML处理时间比7的整个启动时间还长。
希望这能更好地说明我们如何提高效率，以及为什么7与过去相比有一些非常不同的地方。然而，这只是一个开始。请继续关注我的下一篇博客，其中将讨论7的整体路线图。
谢谢！
