Tomcat啓動流程簡析
Tomcat是一款咱們平時開發過程當中最經常使用到的Servlet容器。本系列博客會記錄Tomcat的總體架構、主要組件、IO線程模型、請求在Tomcat內部的流轉過程以及一些Tomcat調優的相關知識。html
力求達到如下幾個目的：java
- 更加熟悉Tomcat的工做機制，工做中遇到Tomcat相關問題可以快速定位，從源頭來解決；
- 對於一些高併發場景可以對Tomcat進行調優；
- 經過對Tomcat源碼的分析，吸取一些Tomcat的設計的理念，應用到本身的軟件開發過程當中。
1. Bootstrap啓動入口
在前面分析Tomcat啓動腳本的過程當中，咱們最後發現startup.bat最後是經過調用Bootstrap這個類的main方法來啓動Tomcat的，因此先去看下Bootstrap這個類。web
public static void main(String args[]) {
synchronized (daemonLock) {
if (daemon == null) {
// Don't set daemon until init() has completed
Bootstrap bootstrap = new Bootstrap();
try {
//建立Bootstrap對象，代用init方法
bootstrap.init();
} catch (Throwable t) {
handleThrowable(t);
t.printStackTrace();
return;
}
daemon = bootstrap;
} else {
// When running as a service the call to stop will be on a new
// thread so make sure the correct class loader is used to
// prevent a range of class not found exceptions.
Thread.currentThread().setContextClassLoader(daemon.catalinaLoader);
}
}
try {
String command = "start";
if (args.length > 0) {
command = args[args.length - 1];
}
if (command.equals("startd")) {
args[args.length - 1] = "start";
daemon.load(args);
daemon.start();
} else if (command.equals("stopd")) {
args[args.length - 1] = "stop";
daemon.stop();
} else if (command.equals("start")) {
//通常狀況下會進入這步，調用Bootstrap對象的load和start方法。
//將Catalina啓動設置成block模式
daemon.setAwait(true);
daemon.load(args);
daemon.start();
if (null == daemon.getServer()) {
System.exit(1);
}
} else if (command.equals("stop")) {
daemon.stopServer(args);
} else if (command.equals("configtest")) {
daemon.load(args);
if (null == daemon.getServer()) {
System.exit(1);
}
System.exit(0);
} else {
log.warn("Bootstrap: command \"" + command + "\" does not exist.");
}
} catch (Throwable t) {
// Unwrap the Exception for clearer error reporting
if (t instanceof InvocationTargetException &&
t.getCause() != null) {
t = t.getCause();
}
handleThrowable(t);
t.printStackTrace();
System.exit(1);
}
}
上面的代碼邏輯比較簡單，若是咱們正常啓動tomcat，會順序執行Bootstrap對象的init()方法， daemon.setAwait(true)、daemon.load(args)和daemon.start()方法。咱們先看下Bootstrap對象的init方法：apache
public void init() throws Exception {
initClassLoaders();
Thread.currentThread().setContextClassLoader(catalinaLoader);
SecurityClassLoad.securityClassLoad(catalinaLoader);
// Load our startup class and call its process() method
if (log.isDebugEnabled())
log.debug("Loading startup class");
Class<?> startupClass = catalinaLoader.loadClass("org.apache.catalina.startup.Catalina");
Object startupInstance = startupClass.getConstructor().newInstance();
// Set the shared extensions class loader
if (log.isDebugEnabled())
log.debug("Setting startup class properties");
String methodName = "setParentClassLoader";
Class<?> paramTypes[] = new Class[1];
paramTypes[0] = Class.forName("java.lang.ClassLoader");
Object paramValues[] = new Object[1];
paramValues[0] = sharedLoader;
Method method =
startupInstance.getClass().getMethod(methodName, paramTypes);
method.invoke(startupInstance, paramValues);
catalinaDaemon = startupInstance;
}
這個方法主要作了如下幾件事：bootstrap
- 建立commonLoader、catalinaLoader、sharedLoader類加載器（默認狀況下這三個類加載器指向同一個對象。建議看看createClassLoader方法，裏面作的事情還挺多，好比裝載catalina.properties裏配置的目錄下的文件和jar包，後兩個加載器的父加載器都是第一個，最後註冊了MBean，能夠用於JVM監控該對象）；
- 實例化一個org.apache.catalina.startup.Catalina對象，並賦值給靜態成員catalinaDaemon，以sharedLoader做爲入參經過反射調用該對象的setParentClassLoader方法。
執行完init()方法，就開始執行bootstrap對象的load和start方法;瀏覽器
private void load(String[] arguments)
throws Exception {
// Call the load() method
String methodName = "load";
Object param[];
Class<?> paramTypes[];
if (arguments==null || arguments.length==0) {
paramTypes = null;
param = null;
} else {
paramTypes = new Class[1];
paramTypes[0] = arguments.getClass();
param = new Object[1];
param[0] = arguments;
}
Method method =
catalinaDaemon.getClass().getMethod(methodName, paramTypes);
if (log.isDebugEnabled())
log.debug("Calling startup class " + method);
method.invoke(catalinaDaemon, param);
}
調用catalinaDaemon對象的load方法，catalinaDaemon這個對象的類型是org.apache.catalina.startup.Catalina。strat方法也是相似的，最後都是調用Catalina的start方法。tomcat
總結下Bootstrap的啓動方法最主要乾的事情就是建立了Catalina對象，並調用它的load和start方法。cookie
2. Catalina的load和start方法
第一節分析到Bootstrap會觸發調用Catalina的load和start方法。架構
/**
* 從註釋能夠看出這個方法的做用是建立一個Server實例
* Start a new server instance.
*/
public void load() {
if (loaded) {
return;
}
loaded = true;
long t1 = System.nanoTime();
//檢查臨時目錄
initDirs();
// Before digester - it may be needed
initNaming();
// Create and execute our Digester
Digester digester = createStartDigester();
InputSource inputSource = null;
InputStream inputStream = null;
File file = null;
try {
try {
file = configFile();
inputStream = new FileInputStream(file);
inputSource = new InputSource(file.toURI().toURL().toString());
} catch (Exception e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("catalina.configFail", file), e);
}
}
if (inputStream == null) {
try {
inputStream = getClass().getClassLoader()
.getResourceAsStream(getConfigFile());
inputSource = new InputSource
(getClass().getClassLoader()
.getResource(getConfigFile()).toString());
} catch (Exception e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("catalina.configFail",
getConfigFile()), e);
}
}
}
// This should be included in catalina.jar
// Alternative: don't bother with xml, just create it manually.
if (inputStream == null) {
try {
inputStream = getClass().getClassLoader()
.getResourceAsStream("server-embed.xml");
inputSource = new InputSource
(getClass().getClassLoader()
.getResource("server-embed.xml").toString());
} catch (Exception e) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("catalina.configFail",
"server-embed.xml"), e);
}
}
}
if (inputStream == null || inputSource == null) {
if (file == null) {
log.warn(sm.getString("catalina.configFail",
getConfigFile() + "] or [server-embed.xml]"));
} else {
log.warn(sm.getString("catalina.configFail",
file.getAbsolutePath()));
if (file.exists() && !file.canRead()) {
log.warn("Permissions incorrect, read permission is not allowed on the file.");
}
}
return;
}
try {
inputSource.setByteStream(inputStream);
digester.push(this);
digester.parse(inputSource);
} catch (SAXParseException spe) {
log.warn("Catalina.start using " + getConfigFile() + ": " +
spe.getMessage());
return;
} catch (Exception e) {
log.warn("Catalina.start using " + getConfigFile() + ": " , e);
return;
}
} finally {
if (inputStream != null) {
try {
inputStream.close();
} catch (IOException e) {
// Ignore
}
}
}
getServer().setCatalina(this);
getServer().setCatalinaHome(Bootstrap.getCatalinaHomeFile());
getServer().setCatalinaBase(Bootstrap.getCatalinaBaseFile());
// Stream redirection
initStreams();
// Start the new server
try {
getServer().init();
} catch (LifecycleException e) {
if (Boolean.getBoolean("org.apache.catalina.startup.EXIT_ON_INIT_FAILURE")) {
throw new java.lang.Error(e);
} else {
log.error("Catalina.start", e);
}
}
long t2 = System.nanoTime();
if(log.isInfoEnabled()) {
log.info("Initialization processed in " + ((t2 - t1) / 1000000) + " ms");
}
}
將上面的代碼精簡下：併發
Digester digester = createStartDigester(); inputSource.setByteStream(inputStream); digester.push(this); digester.parse(inputSource); getServer().setCatalina(this); getServer().init();
作的事情就兩個：
- 建立一個Digester對象（Digester對象的做用就是解析server.xml配置文件，這邊會先加載conf/server.xml文件，找不到的話會嘗試加載server-embed.xml這個配置文件），解析完成後生成org.apache.catalina.core.StandardServer、org.apache.catalina.core.StandardService、org.apache.catalina.connector.Connector、org.apache.catalina.core.StandardEngine、org.apache.catalina.core.StandardHost、org.apache.catalina.core.StandardContext等等一系列對象，這些對象從前到後前一個包含後一個對象的引用（一對一或一對多的關係）。最後將StandardServer賦值給Catalina對象的server屬性；若是你配置了鏈接器組件共享的線程池，還會生成StandardThreadExecutor對象。
- 第二件事就是調用StandardServer的init方法。
臨時總結下：Catalina的load方法的做用主要是解析conf/server.xml，生成StandardServer對象，再觸發StandardServer的init方法。
第一節中還分析到Bootstrap會觸發調用Catalina的start方法。那麼咱們看看start方法中幹了什麼。
/**
* Start a new server instance.
*/
public void start() {
if (getServer() == null) {
load();
}
if (getServer() == null) {
log.fatal("Cannot start server. Server instance is not configured.");
return;
}
long t1 = System.nanoTime();
// Start the new server
try {
getServer().start();
} catch (LifecycleException e) {
log.fatal(sm.getString("catalina.serverStartFail"), e);
try {
getServer().destroy();
} catch (LifecycleException e1) {
log.debug("destroy() failed for failed Server ", e1);
}
return;
}
long t2 = System.nanoTime();
if(log.isInfoEnabled()) {
log.info("Server startup in " + ((t2 - t1) / 1000000) + " ms");
}
// Register shutdown hook
if (useShutdownHook) {
if (shutdownHook == null) {
shutdownHook = new CatalinaShutdownHook();
}
Runtime.getRuntime().addShutdownHook(shutdownHook);
// If JULI is being used, disable JULI's shutdown hook since
// shutdown hooks run in parallel and log messages may be lost
// if JULI's hook completes before the CatalinaShutdownHook()
LogManager logManager = LogManager.getLogManager();
if (logManager instanceof ClassLoaderLogManager) {
((ClassLoaderLogManager) logManager).setUseShutdownHook(
false);
}
}
if (await) {
await();
stop();
}
}
這段代碼最主要的做用就是調用StandardServer對象的start方法。
總結下：Catalina對象的laod和start方法的做用是解析conf/server.xml，生成StandardServer對象，再觸發StandardServer的init方法和start方法。
到這邊爲止咱們能夠看到Tomcat的啓動流程仍是很清晰的，下面繼續看StandardServer的init方法和start到底幹了些什麼。
3.StandardServer的init和start方法
經過尋找StandardServer的init方法，咱們發現StandardServer自己沒有實現這個方法，這個方法是它從父類LifecycleBase中繼承過來的：
@Override
public final synchronized void init() throws LifecycleException {
if (!state.equals(LifecycleState.NEW)) {
invalidTransition(Lifecycle.BEFORE_INIT_EVENT);
}
try {
//發佈初始化容器時間，對應的listener作相應處理
setStateInternal(LifecycleState.INITIALIZING, null, false);
//調用子類的initInternal（）
initInternal();
//發佈容器已經初始化事件，對應的listener作相應處理
setStateInternal(LifecycleState.INITIALIZED, null, false);
} catch (Throwable t) {
handleSubClassException(t, "lifecycleBase.initFail", toString());
}
}
因此調用StandardServer的init方法，實際上是促發了容器初始化事件發佈，而後又調到了StandardServer的initInternal方法。那麼咱們看看StandardServer的start方法的邏輯是什麼。
代碼點進去，發現StandardServer的start方法也是調的父類LifecycleBase中的方法。
@Override
public final synchronized void start() throws LifecycleException {
if (LifecycleState.STARTING_PREP.equals(state) || LifecycleState.STARTING.equals(state) ||
LifecycleState.STARTED.equals(state)) {
if (log.isDebugEnabled()) {
Exception e = new LifecycleException();
log.debug(sm.getString("lifecycleBase.alreadyStarted", toString()), e);
} else if (log.isInfoEnabled()) {
log.info(sm.getString("lifecycleBase.alreadyStarted", toString()));
}
return;
}
if (state.equals(LifecycleState.NEW)) {
init();
} else if (state.equals(LifecycleState.FAILED)) {
stop();
} else if (!state.equals(LifecycleState.INITIALIZED) &&
!state.equals(LifecycleState.STOPPED)) {
invalidTransition(Lifecycle.BEFORE_START_EVENT);
}
try {
//發佈事件
setStateInternal(LifecycleState.STARTING_PREP, null, false);
//調用子類的startInternal
startInternal();
if (state.equals(LifecycleState.FAILED)) {
// This is a 'controlled' failure. The component put itself into the
// FAILED state so call stop() to complete the clean-up.
stop();
} else if (!state.equals(LifecycleState.STARTING)) {
// Shouldn't be necessary but acts as a check that sub-classes are
// doing what they are supposed to.
invalidTransition(Lifecycle.AFTER_START_EVENT);
} else {
//發佈容器啓動事件
setStateInternal(LifecycleState.STARTED, null, false);
}
} catch (Throwable t) {
// This is an 'uncontrolled' failure so put the component into the
// FAILED state and throw an exception.
handleSubClassException(t, "lifecycleBase.startFail", toString());
}
}
從以上init和start方法的定義能夠看到這兩個方法最終將會調用StandardServer中定義的initInternal和startInternal。
先來看initInternal方法
protected void initInternal() throws LifecycleException {
super.initInternal();
// Register global String cache
// Note although the cache is global, if there are multiple Servers
// present in the JVM (may happen when embedding) then the same cache
// will be registered under multiple names
onameStringCache = register(new StringCache(), "type=StringCache");
// Register the MBeanFactory
MBeanFactory factory = new MBeanFactory();
factory.setContainer(this);
onameMBeanFactory = register(factory, "type=MBeanFactory");
// Register the naming resources
globalNamingResources.init();
// Populate the extension validator with JARs from common and shared
// class loaders
if (getCatalina() != null) {
ClassLoader cl = getCatalina().getParentClassLoader();
// Walk the class loader hierarchy. Stop at the system class loader.
// This will add the shared (if present) and common class loaders
while (cl != null && cl != ClassLoader.getSystemClassLoader()) {
if (cl instanceof URLClassLoader) {
URL[] urls = ((URLClassLoader) cl).getURLs();
for (URL url : urls) {
if (url.getProtocol().equals("file")) {
try {
File f = new File (url.toURI());
if (f.isFile() &&
f.getName().endsWith(".jar")) {
ExtensionValidator.addSystemResource(f);
}
} catch (URISyntaxException e) {
// Ignore
} catch (IOException e) {
// Ignore
}
}
}
}
cl = cl.getParent();
}
}
// Initialize our defined Services
for (int i = 0; i < services.length; i++) {
services[i].init();
}
}
重點代碼在最後，循環調用了Service組件的init方法。
再來看StandardServer的startInternal方法
@Override
protected void startInternal() throws LifecycleException {
fireLifecycleEvent(CONFIGURE_START_EVENT, null);
setState(LifecycleState.STARTING);
globalNamingResources.start();
// Start our defined Services
synchronized (servicesLock) {
for (int i = 0; i < services.length; i++) {
services[i].start();
}
}
}
也是循環調用了Service組件的start方法。這邊的Service組件就是在從conf/server.xml中解析出來的StandardService對象，查看下這個類的繼承體系：
LifecycleBase (org.apache.catalina.util)
LifecycleMBeanBase (org.apache.catalina.util)
StandardService (org.apache.catalina.core)
咱們發現這個類繼承體系和StandardServer是同樣的。其實咱們再觀察的仔細一點會發現從conf/server.xml解析胡來的類的繼承體系都是同樣的。因此咱們調用這些類的init和start方法最後仍是會調用到他們的initInternal和startInternal方法。
4. StandardService的initInternal和startInternal方法
先看下StandardService的initInternal方法
@Override
protected void initInternal() throws LifecycleException {
super.initInternal();
//調用engine的initInternal方法，這個方法中也沒作特別重要的操做，只是作了一個getReal操做
if (engine != null) {
engine.init();
}
//StandardThreadExecutor的initInternal方法中沒沒幹什麼事情
// Initialize any Executors
for (Executor executor : findExecutors()) {
if (executor instanceof JmxEnabled) {
((JmxEnabled) executor).setDomain(getDomain());
}
executor.init();
}
// Initialize mapper listener
//這步也沒作什麼重要操做
mapperListener.init();
// Initialize our defined Connectors
// 鏈接器主鍵的初始化，主要是檢查鏈接器的protocolHandler的主鍵，並將其初始化.
synchronized (connectorsLock) {
for (Connector connector : connectors) {
connector.init();
}
}
}
看了上面的代碼，以爲Tomcat源碼邏輯仍是很清晰的。以前在分析Tomcat組件的文章中講到Service組件是有Connector組件、engine組件和一個可選的線程池組成。上面的代碼中正好對應了這三個組件的初始化話。
Connector組件和engine組件的初始化又會觸發他們各自子組件的初始化，因此StandardService的initInternal方法會觸發Tomcat下各種組件的初始化。這邊大體記錄下各個組件初始化話的順序：
- engine組件初始化：engine組件初始化沒作什麼特別的操做，也沒觸發它的子組件（Host、Context和Wrapper組件的初始化），因此這步比較簡單;
- Executor組件的初始化：沒有觸發其餘組件初始化；
- Mapper組件初始化：mapper組件初始化也沒幹什麼重要的操做，也沒觸發其餘子組件初始化；
- Connector組件初始化：檢查鏈接器的protocolHandler的子組件，並觸發其初始化；
- ProtocolHandler組件初始化：觸發Endpoint組件初始化，Endpoint類纔是接收轉化請求的真正的類；
而後再看StandardService的startInternal方法
protected void startInternal() throws LifecycleException {
if(log.isInfoEnabled())
log.info(sm.getString("standardService.start.name", this.name));
setState(LifecycleState.STARTING);
// Start our defined Container first
if (engine != null) {
synchronized (engine) {
engine.start();
}
}
synchronized (executors) {
for (Executor executor: executors) {
executor.start();
}
}
mapperListener.start();
// Start our defined Connectors second
synchronized (connectorsLock) {
for (Connector connector: connectors) {
// If it has already failed, don't try and start it
if (connector.getState() != LifecycleState.FAILED) {
connector.start();
}
}
}
}
邏輯依然很清楚，StandardService會依次觸發各個子組件的start方法。
-
Engine組件的start：Engine組件的start方法組要做用仍是觸發了Host組件的start方法，具體代碼見
protected synchronized void startInternal() throws LifecycleException { // Start our subordinate components, if any if ((loader != null) && (loader instanceof Lifecycle)) ((Lifecycle) loader).start(); logger = null; getLogger(); if ((manager != null) && (manager instanceof Lifecycle)) ((Lifecycle) manager).start(); if ((cluster != null) && (cluster instanceof Lifecycle)) ((Lifecycle) cluster).start(); Realm realm = getRealmInternal(); if ((realm != null) && (realm instanceof Lifecycle)) ((Lifecycle) realm).start(); if ((resources != null) && (resources instanceof Lifecycle)) ((Lifecycle) resources).start(); // 找出Engine的子容器，也就是Host容器 Container children[] = findChildren(); List<Future<Void>> results = new ArrayList<Future<Void>>(); //利用線程池調用Host的start方法 for (int i = 0; i < children.length; i++) { results.add(startStopExecutor.submit(new StartChild(children[i]))); } boolean fail = false; for (Future<Void> result : results) { try { result.get(); } catch (Exception e) { log.error(sm.getString("containerBase.threadedStartFailed"), e); fail = true; } } if (fail) { throw new LifecycleException( sm.getString("containerBase.threadedStartFailed")); } // Start the Valves in our pipeline (including the basic), if any if (pipeline instanceof Lifecycle) ((Lifecycle) pipeline).start(); setState(LifecycleState.STARTING); // Start our thread threadStart(); } -
Host組件的start：通過前面介紹，咱們知道Host組件的start方法最後仍是會調用本身startInternal方法；
-
Context組件的start:觸發Wrapper的start，加載filter、Servlet等；
-
Wrapper組件的start:
這邊咱們重點看下StandardContext的startInternal，這個方法乾的事情比較多：
protected synchronized void startInternal() throws LifecycleException {
if(log.isDebugEnabled())
log.debug("Starting " + getBaseName());
// Send j2ee.state.starting notification
if (this.getObjectName() != null) {
Notification notification = new Notification("j2ee.state.starting",
this.getObjectName(), sequenceNumber.getAndIncrement());
broadcaster.sendNotification(notification);
}
setConfigured(false);
boolean ok = true;
// Currently this is effectively a NO-OP but needs to be called to
// ensure the NamingResources follows the correct lifecycle
if (namingResources != null) {
namingResources.start();
}
// Post work directory
postWorkDirectory();
// Add missing components as necessary
if (getResources() == null) { // (1) Required by Loader
if (log.isDebugEnabled())
log.debug("Configuring default Resources");
try {
setResources(new StandardRoot(this));
} catch (IllegalArgumentException e) {
log.error(sm.getString("standardContext.resourcesInit"), e);
ok = false;
}
}
if (ok) {
resourcesStart();
}
if (getLoader() == null) {
WebappLoader webappLoader = new WebappLoader(getParentClassLoader());
webappLoader.setDelegate(getDelegate());
setLoader(webappLoader);
}
// An explicit cookie processor hasn't been specified; use the default
if (cookieProcessor == null) {
cookieProcessor = new Rfc6265CookieProcessor();
}
// Initialize character set mapper
getCharsetMapper();
// Validate required extensions
boolean dependencyCheck = true;
try {
dependencyCheck = ExtensionValidator.validateApplication
(getResources(), this);
} catch (IOException ioe) {
log.error(sm.getString("standardContext.extensionValidationError"), ioe);
dependencyCheck = false;
}
if (!dependencyCheck) {
// do not make application available if dependency check fails
ok = false;
}
// Reading the "catalina.useNaming" environment variable
String useNamingProperty = System.getProperty("catalina.useNaming");
if ((useNamingProperty != null)
&& (useNamingProperty.equals("false"))) {
useNaming = false;
}
if (ok && isUseNaming()) {
if (getNamingContextListener() == null) {
NamingContextListener ncl = new NamingContextListener();
ncl.setName(getNamingContextName());
ncl.setExceptionOnFailedWrite(getJndiExceptionOnFailedWrite());
addLifecycleListener(ncl);
setNamingContextListener(ncl);
}
}
// Standard container startup
if (log.isDebugEnabled())
log.debug("Processing standard container startup");
// Binding thread
ClassLoader oldCCL = bindThread();
try {
if (ok) {
// Start our subordinate components, if any
Loader loader = getLoader();
if (loader instanceof Lifecycle) {
((Lifecycle) loader).start();
}
// since the loader just started, the webapp classloader is now
// created.
setClassLoaderProperty("clearReferencesRmiTargets",
getClearReferencesRmiTargets());
setClassLoaderProperty("clearReferencesStopThreads",
getClearReferencesStopThreads());
setClassLoaderProperty("clearReferencesStopTimerThreads",
getClearReferencesStopTimerThreads());
setClassLoaderProperty("clearReferencesHttpClientKeepAliveThread",
getClearReferencesHttpClientKeepAliveThread());
setClassLoaderProperty("clearReferencesObjectStreamClassCaches",
getClearReferencesObjectStreamClassCaches());
setClassLoaderProperty("skipMemoryLeakChecksOnJvmShutdown",
getSkipMemoryLeakChecksOnJvmShutdown());
// By calling unbindThread and bindThread in a row, we setup the
// current Thread CCL to be the webapp classloader
unbindThread(oldCCL);
oldCCL = bindThread();
// Initialize logger again. Other components might have used it
// too early, so it should be reset.
logger = null;
getLogger();
Realm realm = getRealmInternal();
if(null != realm) {
if (realm instanceof Lifecycle) {
((Lifecycle) realm).start();
}
// Place the CredentialHandler into the ServletContext so
// applications can have access to it. Wrap it in a "safe"
// handler so application's can't modify it.
CredentialHandler safeHandler = new CredentialHandler() {
@Override
public boolean matches(String inputCredentials, String storedCredentials) {
return getRealmInternal().getCredentialHandler().matches(inputCredentials, storedCredentials);
}
@Override
public String mutate(String inputCredentials) {
return getRealmInternal().getCredentialHandler().mutate(inputCredentials);
}
};
context.setAttribute(Globals.CREDENTIAL_HANDLER, safeHandler);
}
// Notify our interested LifecycleListeners
fireLifecycleEvent(Lifecycle.CONFIGURE_START_EVENT, null);
// Start our child containers, if not already started
for (Container child : findChildren()) {
if (!child.getState().isAvailable()) {
child.start();
}
}
// Start the Valves in our pipeline (including the basic),
// if any
if (pipeline instanceof Lifecycle) {
((Lifecycle) pipeline).start();
}
// Acquire clustered manager
Manager contextManager = null;
Manager manager = getManager();
if (manager == null) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("standardContext.cluster.noManager",
Boolean.valueOf((getCluster() != null)),
Boolean.valueOf(distributable)));
}
if ( (getCluster() != null) && distributable) {
try {
contextManager = getCluster().createManager(getName());
} catch (Exception ex) {
log.error("standardContext.clusterFail", ex);
ok = false;
}
} else {
contextManager = new StandardManager();
}
}
// Configure default manager if none was specified
if (contextManager != null) {
if (log.isDebugEnabled()) {
log.debug(sm.getString("standardContext.manager",
contextManager.getClass().getName()));
}
setManager(contextManager);
}
if (manager!=null && (getCluster() != null) && distributable) {
//let the cluster know that there is a context that is distributable
//and that it has its own manager
getCluster().registerManager(manager);
}
}
if (!getConfigured()) {
log.error(sm.getString("standardContext.configurationFail"));
ok = false;
}
// We put the resources into the servlet context
if (ok)
getServletContext().setAttribute
(Globals.RESOURCES_ATTR, getResources());
if (ok ) {
if (getInstanceManager() == null) {
javax.naming.Context context = null;
if (isUseNaming() && getNamingContextListener() != null) {
context = getNamingContextListener().getEnvContext();
}
Map<String, Map<String, String>> injectionMap = buildInjectionMap(
getIgnoreAnnotations() ? new NamingResourcesImpl(): getNamingResources());
setInstanceManager(new DefaultInstanceManager(context,
injectionMap, this, this.getClass().getClassLoader()));
}
getServletContext().setAttribute(
InstanceManager.class.getName(), getInstanceManager());
InstanceManagerBindings.bind(getLoader().getClassLoader(), getInstanceManager());
}
// Create context attributes that will be required
if (ok) {
getServletContext().setAttribute(
JarScanner.class.getName(), getJarScanner());
}
// Set up the context init params
mergeParameters();
// Call ServletContainerInitializers
for (Map.Entry<ServletContainerInitializer, Set<Class<?>>> entry :
initializers.entrySet()) {
try {
entry.getKey().onStartup(entry.getValue(),
getServletContext());
} catch (ServletException e) {
log.error(sm.getString("standardContext.sciFail"), e);
ok = false;
break;
}
}
// Configure and call application event listeners
if (ok) {
if (!listenerStart()) {
log.error(sm.getString("standardContext.listenerFail"));
ok = false;
}
}
// Check constraints for uncovered HTTP methods
// Needs to be after SCIs and listeners as they may programmatically
// change constraints
if (ok) {
checkConstraintsForUncoveredMethods(findConstraints());
}
try {
// Start manager
Manager manager = getManager();
if (manager instanceof Lifecycle) {
((Lifecycle) manager).start();
}
} catch(Exception e) {
log.error(sm.getString("standardContext.managerFail"), e);
ok = false;
}
// Configure and call application filters
if (ok) {
if (!filterStart()) {
log.error(sm.getString("standardContext.filterFail"));
ok = false;
}
}
// Load and initialize all "load on startup" servlets
if (ok) {
if (!loadOnStartup(findChildren())){
log.error(sm.getString("standardContext.servletFail"));
ok = false;
}
}
// Start ContainerBackgroundProcessor thread
super.threadStart();
} finally {
// Unbinding thread
unbindThread(oldCCL);
}
// Set available status depending upon startup success
if (ok) {
if (log.isDebugEnabled())
log.debug("Starting completed");
} else {
log.error(sm.getString("standardContext.startFailed", getName()));
}
startTime=System.currentTimeMillis();
// Send j2ee.state.running notification
if (ok && (this.getObjectName() != null)) {
Notification notification =
new Notification("j2ee.state.running", this.getObjectName(),
sequenceNumber.getAndIncrement());
broadcaster.sendNotification(notification);
}
// The WebResources implementation caches references to JAR files. On
// some platforms these references may lock the JAR files. Since web
// application start is likely to have read from lots of JARs, trigger
// a clean-up now.
getResources().gc();
// Reinitializing if something went wrong
if (!ok) {
setState(LifecycleState.FAILED);
} else {
setState(LifecycleState.STARTING);
}
}
上面的代碼有4處重點：調用ServletContainerInitializers、啓用Listener、啓用Filter和啓用startup的Servlet。這個和咱們平時對Tomcat啓動流程的認知是一致的。
到這裏整個Container組件（包括Engine、Host、Context和Wrapper組件）的start方法調用就結束了。接下來是Connector和Mapper組件的start。
//MapperListenner的startInternal
public void startInternal() throws LifecycleException {
setState(LifecycleState.STARTING);
Engine engine = service.getContainer();
if (engine == null) {
return;
}
findDefaultHost();
addListeners(engine);
Container[] conHosts = engine.findChildren();
for (Container conHost : conHosts) {
Host host = (Host) conHost;
if (!LifecycleState.NEW.equals(host.getState())) {
// Registering the host will register the context and wrappers
registerHost(host);
}
}
}
以上方法的主要做用是將Host組件和域名映射起來。
最後看下Connector組件的start：
protected void startInternal() throws LifecycleException {
// Validate settings before starting
if (getPortWithOffset() < 0) {
throw new LifecycleException(sm.getString(
"coyoteConnector.invalidPort", Integer.valueOf(getPortWithOffset())));
}
setState(LifecycleState.STARTING);
try {
//促發protocolHandler組件的start，最後促發endpoint組件的start
//觸發endpoint時會創建exceutor線程池，默認的話核心線程數10，最大線程數200
//創建poller線程，最大是2個線程，若是你機器cpu的核數小於2的話就創建1個
//創建accetpor線程，默認是1個（能夠看看Acceptor這個類的源代碼，瞭解下怎麼接收請求的）
protocolHandler.start();
} catch (Exception e) {
throw new LifecycleException(
sm.getString("coyoteConnector.protocolHandlerStartFailed"), e);
}
}
經過以上一些列複雜的調用過程，最終執行完全部在server.xml裏配置的節點的實現類中initInternal和startInternal方法。上面提到的org.apache.catalina.core.StandardServer、org.apache.catalina.core.StandardService、org.apache.catalina.connector.Connector、org.apache.catalina.core.StandardEngine、org.apache.catalina.core.StandardHost、org.apache.catalina.core.StandardContext等等組件的這兩個方法都會調用到。
至此，Tomcat已經能開始響應瀏覽器發過來的請求了。至於具體的Tomcat響應請求流程會在後續博客中介紹。
5. 總結
看了整個啓動流程，雖然邏輯是比較清楚的，可是流程比較上，因此有必要作下總結：
-
step1：Bootstrap做爲整個Tomcat主啓動類，最主要的功能是建立Catalina對象，並調用它的load和start方法；
-
step2：Catalina的load方法的做用主要是解析conf/server.xml，生成StandardServer對象（此時生成StandardServer對象中已經包含了各類子組件，好比StandardService、StandardEngine等），再觸發StandardServer的init方法；Catalina的start方法又觸發了StandardServer的start方法；
-
step3：StandardServer的init方法和start方法會依次觸發各個子組件的initInternal和startInternal方法。大體的觸發順序是：
Engine組件的initInternal（這邊要注意的是Engine組件並無觸發它的子組件Host、Context和Wrapper的initInternal）-->Executor組件initInternal（處理請求的工做線程池）-->Mapper組件初始化（mapper組件初始化也沒幹什麼重要的操做，也沒觸發其餘子組件初始化）-->Connector組件初始化（檢查鏈接器的protocolHandler的子組件，並觸發其初始化）-->ProtocolHandler組件初始化(觸發Endpoint組件初始化)
Engine組件的startInternal（主要做用是觸發Host組件的start）-->Host組件的startInternal（主要做用是觸發Context組件的startInternal）-->Contextz組件的startInternal（加載調用ServletContainerInitializers、加載Listener、加載filtr和startup的Servlet，而且觸發Wrapper組件的startInternal）-->Wrapper組件的startInternal（加載映射Servlet）-->Mapper組件的startInternal（將域名和Host組件映射起來）-->Connector組件的startInternal（protocolHandler組件的start，最後促發endpoint組件的start）
參考
相關文章
- 1. Tomcat啓動流程解析
- 2. springboot啓動流程簡析
- 3. Flutter啓動流程簡析
- 4. tomcat啓動流程
- 5. SpringBoot 中啓動 Tomcat 流程
- 6. SpringBoot啓動流程簡析（一）
- 7. Linux系統啓動流程簡析
- 8. Spring啓動流程簡要分析
- 9. 【Spring啓動過程分析】啓動流程簡介
- 10. 【Spring啓動過程分析】（1）啓動流程簡介
- 更多相關文章...
- • 啓動MySQL服務 - MySQL教程
- • SVN 啓動模式 - SVN 教程
- • Github 簡明教程
- • Git可視化極簡易教程 — Git GUI使用方法
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
歡迎關注本站公眾號,獲取更多信息
相關文章