JBoss Application Server的启动过程

本文以JBoss Application Server 4.2.1 GA（以下简称JBoss）为例，介绍它在Windows平台上的启动过程。为了方便叙述，对平台环境做以下假定：Java运行时的安装路径为C:\Java，JBoss的安装路径为C:\JBoss。

既然用100% Java编写的JBoss具有跨平台的特性，那为什么还要强调Windows平台呢？这是因为，JBoss的启动是从平台相关的脚本文件开始的，而在不同平台上的脚本文件是不同的。例如，Window平台上的脚本文件是run.bat，linux平台上的脚本是run.sh。两个文件的内容有很大不同，功能也许差不多，无非是配置启动环境，但是也有可能存在平台相关的因素。我只看了run.bat，对run.sh并不了解，为谨慎起见，我只介绍run.bat，对run.sh不作阐述。

在介绍JBoss启动过程之前，我想先介绍一下JBoss的结构特征，这将有利于大家理解启动过程。JBoss基于JMX框架，它的结构就是一个MBeanSserver以及一些挂在MBeanServer上的MBean。MBean提供功能，MBeanServer是MBean之间的通信总线。JMX框架的好处就是给JBoss带来了高度的灵活性、可配置性。可配置性也是JBoss的核心理念之一，几乎所有的JBoss部件都可以被替换。JBoss通过系统属性、配置文件等多种方法，帮助实现高度的可配置性。我们可以通过设置系统属性，或者通过编辑配置文件，来定制自己的JBoss版本。这种可配置性体现在JBoss的各个角落，启动过程只能窥一斑，若欲知全豹，可以研究一下JBoss的EJB容器等其它部件。

介绍完JBoss的结构特征，我们开始进入JBoss的启动过程。整个过程可以分为六个阶段，下面将依次介绍。

<!--[if !supportLists]-->一、<!--[endif]-->执行启动脚本，配置启动环境

JBoss的启动过程从执行run.bat开始，run.bat的主要工作就是配置启动环境。

JBoss的启动环境其实是一些启动参数，例如JBoss的安装路径、java命令的参数、JBoss的类路径等。如果在配置过程中发生错误，run.bat的执行将被中断。

run.bat将配置以下启动参数：

JBOSS_HOME

JBoss的安装路径，其值为C:\JBoss

PATH

将C:\JBoss\bin\native添加到PATH中，native下的文件是平台相关的，可以优化JBoss的性能。

JAVA

java.exe文件的路径，其值为C:\Java\bin\java

JAVA_OPTSB

java命令的参数，其值为-Dprogram.name=run.bat –server-Xms128m –Xmx512m –Dsun.rmi.dgc.client.gcInterval=3600000 –Dsun.rmi.dgc.server.gcInterval=3600000

JBOSS_CLASSPATH

JBoss的启动类路径，其值为C:\Java\lib\tools.jar;C:\JBoss\bin\run.jar。JBoss的启动前期需要的类文件都在这两个jar中。

如果没有设置系统环境变量JAVA_HOME，那么run.bat的执行将被中断，JBoss启动失

败。因此，在安装好JBoss后，一定要设置JAVA_HOME系统环境变量。

如果run.bat执行顺利，那么在最后，将会执行以下命令：

C:\Java\bin\java -Dprogram.name=run.bat –server-Xms128m –Xmx512m –Dsun.rmi.dgc.

client.gcInterval=3600000 –Dsun.rmi.dgc.client.gcInterval=3600000 -Djava.endorsed.dirs=

C:\JBoss\lib\endorsed –classpath C:\Java\lib\tools.jar;C:\JBoss\bin\run.jar org.jboss.Main\%*

%*代表run.bat后面的启动参数。

从这条命令开始，真正运行JBoss的代码。

<!--[if !supportLists]-->二、<!--[endif]-->JBoss启动的入口

JBoss的魔术从Main.main方法开始。Main这个类位于run.jar中。Main.main方法创建了一个名为”jboss”的线程组，然后创建并运行该线程组的线程”main”。”main”线程开始运行后，Main.main方法执行完毕，主线程也随之结束。”main”线程的主要工作是调用Main.boot方法。

Main.boot方法的主要工作是处理命令行参数，然后创建并运行一个服务器实例。当服务器实例开始运行后，jboss的启动过程也就成功结束了。下面的几个阶段都是boot方法的执行过程。

<!--[if !supportLists]-->三、<!--[endif]-->处理命令行参数

boot方法调用Main.processCommandLine方法，来处理命令行参数。这里的命令行参数其实就是main方法的args参数，它作为实参传递给processCommandLine方法。

processCommandLine方法使用了GNU-getopt程序包来解析命令行参数，对不同的命令行参数有不同的处理方式，简单概括如下：

部分参数被简单处理后，程序直接退出。这些参数包括：

-h 显示帮助消息。

-V 显示版本信息。版本信息从run.jar中的MANIFEST.MF文件中获得。

部分参数被保存在服务器属性（Main.props）中，这些参数包括：

-p 补丁目录。

-n 从网络启动的url。

-c 服务器配置的名称，预定义的有三种，minimal、default和all。当然也可以自定义。

-b 所有JBoss服务绑定的地址，如果需要从其它机器访问JBoss服务，则必须配置该参数。

-g HA分区的名称

-u UDP多播地址

部分参数被保存在Main的成员变量中，这些参数包括：

-d 启动补丁目录 保存在URL bootURL中

-B 添加到启动类路径的额外的库 保存在List bootLibraries中

-L 添加到类加载路径的额外的库 保存在List extraLibraries中

-C 添加到类加载路径的额外的url 保存在List extraClasspath中

部分参数被保存在系统属性中，这些参数包括：

-D 系统属性

-P 从给定url加载的属性

-l 指定日志插件类性，目前有log4j和jdk两种。

processCommandLine方法执行完毕后，boot方法将加载、创建并运行一个服务器实例。

<!--[if !supportLists]-->四、<!--[endif]-->加载并创建服务器实例

服务器实例是一个运行时对象，这个对象代表了运行着的JBoss应用服务器。启动一个JBoss应用服务器，就会有一个服务器实例与之对应。在JBoss中，服务器实例的实现是可以配置的，也就是说，服务器类不是固化的，而是可以替换的。这就带来一个问题：JBoss必须在启动的过程中搜索并加载服务器类。

搜索并加载服务器实例类的工作由一个辅助类完成，它的全限定类名是org.jboss.system.server.ServerLoader。这个类会创建一个特定的类加载器，并使用这个类加载器加载服务器类，然后利用反射机制，创建一个服务器实例。

boot方法首先创建一个ServerLoader实例，我们把它称为loader，然后boot方法将一些url添加到loader中。我们把这些url称为服务器搜索路径。loader就是在服务器搜索路径中搜索服务器类。服务器搜索路径包括：

bootURL 由-d参数提供。如果bootURL是文件目录，则其下的jar的url也被添加。

bootLibraries 由-B参数提供。

Endorsed jars 位于C:\JBoss\lib\endorsed下的所有jar包。

jmxLibs C:\JBoss\lib\jboss-jmx.jar。

concurrentLib C:\JBoss\lib\concurrent.jar。

extraLibraries 由-L参数提供。

extraClasspath 由-C参数提供。

loader自带的url log4j-boot.jar、jboss-common.jar、jboss-system.jar、jboss-xml-binding.jar。

添加完服务器搜索路径后，boot方法调用了loader的load方法。load方法以服务器

搜索路径作为参数，创建一个类加载器，并使用它搜索和加载服务器类。如果成功加载，就利用放射机制，创建一个服务器实例，我们把它称为server。

默认的服务器类是org.jboss.system.server.ServerImpl，它位于C:\JBoss

\lib\jboss-system.jar中，并不在jboss的类路径中。因此，loader必须创建自己的类加载器，使用服务器搜索路径作为类搜索路径，才能够找到ServerImpl。通过设置jboss.server.type系统属性，也可以使用自定义的服务器类。当然，前提是要保证自定义的服务器类的类文件要在服务器搜索路径中。

服务器实例创建完毕后，还需要对它进行配置，这就是下面的初始化工作。

<!--[if !supportLists]-->五、<!--[endif]-->初始化服务器实例

初始化服务器实例的主要工作就是将服务器配置信息封装到一个对象中。这个对象是类org.jboss.system.server.ServerConfigImpl的实例。它包括了服务器实例的基本配置信息，例如JBoss的安装路径、服务器的根目录、服务器的日志目录、服务器的临时目录、服务器的库路径等。

boot方法调用server的init方法，开始初始化工作。Init方法将初始化工作委派给server.

.doInit方法。doInit方法创建并配置ServerConfigImpl对象，并在最后在控制台和日志中打印出服务器的配置信息。

ServerConfigImpl对象是一个MBean，因此，用户可以利用jmx控制台查看服务器实例的配置信息。

初始化完毕后，就要启动服务器实例了。

<!--[if !supportLists]-->六、<!--[endif]-->启动服务器实例

启动服务器实例是一个复杂的过程，其中有很多的工作需要完成。前面已经提到，JBoss是基于JMX框架的，JBoss的主要功能都是以MBean的形式作为服务提供的，服务之间利用JMX总线进行通信。直到目前为止，我们还没有看到JMX相关的工作。因此，在服务器实例的启动过程中，首要的工作就是要搭建JMX框架。JMX框架搭建完毕后，JBoss需要创建几个基本的服务，这些服务正是以MBean的形式，挂在JMX框架上。之后，JBoss开始了部署过程。JBoss预配置的服务、用户的部署单元都在这个阶段被部署、启动。

boot方法调用server.start方法，开始了启动过程。start方法将启动工作委派给了server.

doStart方法。doStart方法依次完成以下工作：

<!--[if !supportLists]-->1. <!--[endif]-->创建并启动计时器

这个计时器是用来计算JBoss启动的时间，JBoss启动成功后，会在控制台输出启动过程所耗的时间，背后的秘密就在这里。（这个无关紧要，为了完整性介绍一下）。

<!--[if !supportLists]-->2. <!--[endif]-->创建MBeanServer实例

MBeanServer是JMX框架的核心。JBoss需要创建一个MBeanServer实例。，MBeanServer的实现也是可以配置的。目前可以使用两种MBeanServer，一种是jvm platform MBeanServer，它是Java平台提供的；另一种是JBoss提供的，全限定类名为org.jboss.mx.server.MBeanServerImpl。通过设置javax.management.builder.initial系统属性，也可以使用自定义的MBeanServer。那么JBoss究竟使用的是哪种实现呢？如果Java版本达到或高于5.0，且jboss.platform.mbeanserver系统属性为true，则使用jvm platform MBeanServer，否则都使用JBoss提供的MBeanServerImpl。（这一点说得并不准确，涉及到LazyMBeanServer，我还不太清除。大家可以认为，绝大部分情况下，都是用JBoss提供的MBeanServerImpl）。

<!--[if !supportLists]-->3. <!--[endif]-->创建并注册基础服务

在创建MBeanServerImpl的过程中，会创建以下3个MBean：

第一个MBean是javax.management.MBeanServerDelegate,

ObjectName=JMImplementation:type=MBeanServerDelegate

第二个MBean是一个动态MBean，org.jboss.mx.modelmbean.XMBean,

ObjectName=JMImplementation:type=MBeanRegistry

第三个MBean是org.jboss.mx.loading.UnifiedLoaderRepository3,

ObjectName=JMImplementation:service=LoaderRepository,

name=Default

第一个MBean是在调用MBeanServerImpl之前创建的，后面两个MBean实在MBeanServerImpl的构造函数中创建的。第二个MBean是用来MBeanServer的注册表，所有挂在MBeanServer上的MBean都被注册到注册表中。第三个MBean与JBoss的类加载架构有关，也是基础服务之一。

服务器server和ServerConfigImpl也都是MBean，也都被注册到MBeanServer，ObjectName分别为jboss.system:type=Server和jboss.system:type=ServerConfig。

然后，doStart方法创建并注册以下3个MBean：

第一个MBean是org.jboss.system.server.ServerInfo，

ObjectName= jboss.system:type=ServerInfo

第二个MBean是org.jboss.system.ServiceController，

ObjectName= jboss.system:service=ServiceController

第三个MBean是org.jboss.deployment.MainDeployer，

ObjectName= jboss.system:service=MainDeployer

第一个MBean主要封装了JBoss运行的软硬件平台的信息，包括主机地址、J操作系统版本、Java版本等。

第二个MBean是用来控制MBean的生命周期。JMX规范没有规定MBean的生命周期，JBoss对JMX的扩充。每个MBean可以有若干生命周期回调方法，JBoss的JMX框架会在特定的时候调用这些回调方法。第二个MBean就是负责调用MBeabn的生命周期回调方法。

第三个MBean是主部署器，所有的部署单元都由它部署。它会根据服务和部署单元的类型，将部署任务委派给相应的子部署器。

接着，doStart方法调用Runtime.getRuntime.setShutdownHook方法，安装jvm关机钩子。这个钩子执行JBoss关闭时必要的清理工作，包括销毁已有部署、移除MBean等。

再接着，doStart方法创建并注册两个子部署器JARDeployer和SARDeployer，它们也都是MBean。JARDeployer是用来不包括WEB-INF和META-IN目录的JAR包的子部署器。SARDeployer是用来部署JBoss MBean SAR服务的子部署器，它可以部署.sar的部署包和目录，以及以-server.xml结尾的XML服务描述符文件。

除了上面两种子部署器，还有很多其它类型的子部署器。它们作为部署单元，被SARDeployer创建。（有点奇怪吧，这些部署器本身也是部署单元）

最后，doStart方法开始创建预配置的服务，JavaEE规范规定的服务，例如事务管理器、安全管理器就在包括在其中。

<!--[if !supportLists]-->4. <!--[endif]-->部署预配置的服务

预配置的服务都在C:\JBoss\server\conf\jboss-service.xml被定义。它们都是以MBean的形式存在。具体包括哪些服务，我就不在详细阐述。不过，其中一个服务我后面会介绍到，类名是org.jboss.deployment.scanner.URLDeploymentScanner。它与下一个阶段紧密相关。

doStart方法”C:\JBoss\server\conf\jboss-service.xml”为参数，调用MainDeployer.

deploy方法。因为部署单元的名称以-server.xml结尾，MainDeployer将部署任务委派给SARDeployer。SARDeployer进行真正的部署工作。

除了jboss=service.xml中配置的服务，还有其它很多部署单元，包括用户创建的部署单元，是怎么部署的呢？答案就在下个阶段。

<!--[if !supportLists]-->5. <!--[endif]-->部署所有的部署单元

还记得上面提到的URLDeploymentScanner吗？它是实现JBoss热部署功能的重要角色。热部署功能是指，如果你可以在JBoss运行的时候添加、删除、修改部署单元，而不需要重启JBoss。这个功能大大方便了JavaEE应用的开发、调试和部署。

实现热部署功能是很复杂的，其中有很多技术问题需要解决。例如类加载器问题，JBoss统一类加载器架构就是为了解决这个问题。我们不考虑这些技术问题，最直接的问题就是需要有个机制来监视部署单元的变化。

我们应该需要一个线程去监视所有的部署单元，如果有变化，就要重新部署。为了监视的方便，我们应该把所有的部署单元放在一个目录下。如果一个部署单元被添加到这个目录，JBoss应该自动部署它；如果这个目录下的一个部署单元被修改了，JBoss应该自动重新部署它；如果这个目录下的一个部署单元被删除了，JBoss应该自动销毁已部署的单元。

不错，JBoss正是这样做的。所有的需要动态部署单元，都被放到C:\JBoss\server\default\deploy目录下。而URLDeploymentScanner正是监视该目录的MBean，它会启动一个线程，周期性地扫描该目录下的部署单元，如果有变化，就会进行相应的处理。如果我们需要部署一个组件，只要将它copy到deploy目录即可。如果不需要该组建了，只需将它从deploy目录删除。

deploy下的部署单元并不仅仅是用户开发的部署单元，很多都是JBoss提供的企业级服务。如果需要详细了解，可以浏览一下该目录。

<!--[if !supportLists]-->6. <!--[endif]-->启动生命维持线程

生命维持线程是为了避免JBoss的jvm停机的。因为boot方法执行结束后，”main”线程也随之结束。如果没有其它线程存在，JBoss的jvm将停机。因此，boot方法在最后会创建并运行一个LifeThread，以维持jvm的运行。也许有人会问，不是有一个监视deploy目录的线程吗，何必要增加一个线程？问题在于，JBoss是高度可定制的，URLDeploymentScanner未必一定存在。创建LifeThread的意义就是，保证至少有一个线程会维持JBoss jvm的运行。

至此，JBoss的启动过程成功结束。最终的结果就是创建了一个JMX的框架：一个MBeanServer，以及众多的MBean挂在上面。MBean代表了JBoss提供的所有功能，MBeanServer是MBean之间的通信总线。当然，还有一个勤劳的小线程维持着jvm的运行。

上面所叙述的所有内容，是我在研究了JBoss的部分源代码，以及参考了部分书籍后，得出的体会。可能会叙述不准确、甚至错误的地方，欢迎大家指正！