背景：一個剛開發完的小專案部署到測試環境，總是部署失敗，直觀的報錯是error日誌中有dubbo埠被佔用。專案為springmvc框架+tomcat。

錯誤日誌為：

[0518 19:36:41 354 ERROR] [main] web.context.ContextLoader - Context initialization failed

com.alibaba.dubbo.rpc.RpcException: Fail to start server(url: dubbo://192.168.1.121:18191/com.tongbanjie.security.facade.api.AuthCodeValidationFacade?

anyhost=true&application=security&channel.readonly.sent=true&codec=dubbo&default.retries=0&default.timeout=30000&dubbo=2.5.3&heartbeat=60000&interface

=com.tongbanjie.security.facade.api.AuthCodeValidationFacade&methods=verifyAuthCode&pid=16819&revision=1.0-SNAPSHOT&side=provider&timestamp=1463571401

299&version=2.0) Failed to bind NettyServer on /192.168.1.121:18191, cause: Failed to bind to: /0.0.0.0:18191

        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.createServer(DubboProtocol.java:289)

        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.openServer(DubboProtocol.java:266)

        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.export(DubboProtocol.java:253)

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper.export(ProtocolFilterWrapper.java:55)

        at com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper.export(ProtocolListenerWrapper.java:56)

        at com.alibaba.dubbo.rpc.Protocol$Adpative.export(Protocol$Adpative.java)

        at com.alibaba.dubbo.registry.integration.RegistryProtocol.doLocalExport(RegistryProtocol.java:153)

        at com.alibaba.dubbo.registry.integration.RegistryProtocol.export(RegistryProtocol.java:107)

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper.export(ProtocolFilterWrapper.java:53)

        at com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper.export(ProtocolListenerWrapper.java:54)

        at com.alibaba.dubbo.rpc.Protocol$Adpative.export(Protocol$Adpative.java)

        at com.alibaba.dubbo.config.ServiceConfig.doExportUrlsFor1Protocol(ServiceConfig.java:485)

        at com.alibaba.dubbo.config.ServiceConfig.doExportUrls(ServiceConfig.java:281)

        at com.alibaba.dubbo.config.ServiceConfig.doExport(ServiceConfig.java:242)

        at com.alibaba.dubbo.config.ServiceConfig.export(ServiceConfig.java:143)

        at com.alibaba.dubbo.config.spring.ServiceBean.onApplicationEvent(ServiceBean.java:109)

        at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:96)

        at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:334)

        at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:948)

        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)

        at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:410)

        at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)

        at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)

        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4210)

        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4709)

        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799)

        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779)

        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:583)

        at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079)

        at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002)

        at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506)

        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317)

        at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324)

        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)

        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065)

        at org.apache.catalina.core.StandardHost.start(StandardHost.java:822)

        at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)

        at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)

        at org.apache.catalina.core.StandardService.start(StandardService.java:525)

        at org.apache.catalina.core.StandardServer.start(StandardServer.java:754)

        at org.apache.catalina.startup.Catalina.start(Catalina.java:595)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:601)

        at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:601)

        at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)

Caused by: com.alibaba.dubbo.remoting.RemotingException: Failed to bind NettyServer on /192.168.1.121:18191, cause: Failed to bind to: /0.0.0.0:18191

        at com.alibaba.dubbo.remoting.transport.AbstractServer.<init>(AbstractServer.java:72)

        at com.alibaba.dubbo.remoting.transport.netty.NettyServer.<init>(NettyServer.java:63)

        at com.alibaba.dubbo.remoting.transport.netty.NettyTransporter.bind(NettyTransporter.java:33)

        at com.alibaba.dubbo.remoting.Transporter$Adpative.bind(Transporter$Adpative.java)

        at com.alibaba.dubbo.remoting.Transporters.bind(Transporters.java:48)

        at com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchanger.bind(HeaderExchanger.java:41)

        at com.alibaba.dubbo.remoting.exchange.Exchangers.bind(Exchangers.java:63)

        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol.createServer(DubboProtocol.java:287)

        ... 50 more

Caused by: org.jboss.netty.channel.ChannelException: Failed to bind to: /0.0.0.0:18191

        at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:303)

        at com.alibaba.dubbo.remoting.transport.netty.NettyServer.doOpen(NettyServer.java:94)

        at com.alibaba.dubbo.remoting.transport.AbstractServer.<init>(AbstractServer.java:67)

        ... 57 more

Caused by: java.net.BindException: 地址已在使用

        at sun.nio.ch.Net.bind0(Native Method)

        at sun.nio.ch.Net.bind(Net.java:344)

        at sun.nio.ch.Net.bind(Net.java:336)

        at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:199)

        at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)

        at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.bind(NioServerSocketPipelineSink.java:148)

        at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleServerSocket(NioServerSocketPipelineSink.java:100)

        at org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:74)

        at org.jboss.netty.channel.Channels.bind(Channels.java:468)

        at org.jboss.netty.channel.AbstractChannel.bind(AbstractChannel.java:192)

        at org.jboss.netty.bootstrap.ServerBootstrap$Binder.channelOpen(ServerBootstrap.java:348)

        at org.jboss.netty.channel.Channels.fireChannelOpen(Channels.java:176)

        at org.jboss.netty.channel.socket.nio.NioServerSocketChannel.<init>(NioServerSocketChannel.java:85)

        at org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory.newChannel(NioServerSocketChannelFactory.java:142)

        at org.jboss.netty.channel.socket.nio.NioServerSocketChannelFactory.newChannel(NioServerSocketChannelFactory.java:90)

        at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:282)

        ... 59 more

首先想到是看看什麼佔用了18191埠：

[[email protected] app]# netstat -tunlp|grep 18191
tcp        0      0 :::18191                    :::*                        LISTEN      23049/jsvc.exec

[[email protected] app]# ps -ef|grep 23049
tomcat   23049 23048  0 May18 ?        00:04:14 jsvc.exec -java-home /usr/java/jdk1.7.0_04 -user tomcat ......

佔用18191的就是部署這個應用的tomcat例項。

kill -9 幹掉例項，重啟，一樣報錯。

同事換了個埠28191，還是報類似的錯誤，只是變成了28191埠被佔用。

error日誌只有埠被佔用一條錯誤資訊，那就看看其他日誌。

tomcat日誌，catalina.log：

五月 18, 2016 7:36:36 下午 org.apache.catalina.loader.WebappClassLoader validateJarFile

資訊: validateJarFile(/data/www/ROOT/security/security/WEB-INF/lib/servlet-api-2.5.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offendi

ng class: javax/servlet/Servlet.class

五月 18, 2016 7:36:41 下午 org.apache.catalina.core.StandardContext start

嚴重: Error listenerStart

五月 18, 2016 7:36:41 下午 org.apache.catalina.core.StandardContext start

嚴重: Context [/security] startup failed due to previous errors

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc

嚴重: The web application [/security] registered the JDBC driver [com.alibaba.druid.proxy.DruidDriver] but failed to unregister it when the web applic

ation was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc

嚴重: The web application [/security] registered the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was stop

ped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [DubboRegistryFailedRetryTimer-thread-1] but has failed to stop it. This

is very likely to create a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [ZkClient-EventThread-69-zk.tbj.com:2181] but has failed to stop it. This

 is very likely to create a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [main-SendThread(zk.tbj.com:2181)] but has failed to stop it. This is ver

y likely to create a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [main-EventThread] but has failed to stop it. This is very likely to crea

te a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [DubboSaveRegistryCache-thread-1] but has failed to stop it. This is very

 likely to create a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [DubboClientReconnectTimer-thread-1] but has failed to stop it. This is v

ery likely to create a memory leak.

五月 18, 2016 7:36:41 下午 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads

嚴重: The web application [/security] appears to have started a thread named [NettyClientBoss-thread-1] but has failed to stop it. This is very likely

 to create a memory leak.

其中：

五月 18, 2016 7:36:41 下午 org.apache.catalina.core.StandardContext start

嚴重: Error listenerStart

五月 18, 2016 7:36:41 下午 org.apache.catalina.core.StandardContext start

嚴重: Context [/security] startup failed due to previous errors

結合error日誌時間點，應該是dubbo端口占用導致spring啟動失敗，從而此處報錯。

上邊還有一個錯誤資訊：

五月 18, 2016 7:36:36 下午 org.apache.catalina.loader.WebappClassLoader validateJarFile

資訊: validateJarFile(/data/www/ROOT/security/security/WEB-INF/lib/servlet-api-2.5.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offendi

ng class: javax/servlet/Servlet.class

這個應該是應用打的包中包含servlet.jar，解決辦法是在maven中把這個包的scope設定為provided，這個應該不是導致我們啟動失敗的原因。

那麼究竟是什麼導致dubbo埠被佔用的呢？？

繼續找日誌，tomcat日誌，應用的error日誌，都已經看了，那隻剩下應用的info日誌了。沒辦法大量的info日誌，一條一條讀吧。

還真讓我發現了問題！！

0518 21:00:04 679 INFO ] [main] web.context.ContextLoader - Root WebApplicationContext: initialization started

[0518 21:00:04 868 INFO ] [main] context.support.XmlWebApplicationContext - Refreshing Root WebApplicationContext: startup date [Wed May 18 21:00:04 C

ST 2016]; root of context hierarchy

[0518 21:00:05 021 INFO ] [main] factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [META-INF/spring/security

-context.xml]

.........

[0518 21:00:12 567 INFO ] [main] web.servlet.DispatcherServlet - FrameworkServlet 'springmvc': initialization completed in 1209 ms

[0518 21:00:15 330 INFO ] [main] web.context.ContextLoader - Root WebApplicationContext: initialization started

[0518 21:00:15 434 INFO ] [main] context.support.XmlWebApplicationContext - Refreshing Root WebApplicationContext: startup date [Wed May 18 21:00:15 C

ST 2016]; root of context hierarchy

..........

Root WebApplicationContext 啟動了兩次，第二次報錯了，容器關閉。啟動兩次，這就可以理解為什麼dubbo埠怎麼改都會被佔用了。

那麼問題來了，為什麼會啟動兩次呢？本地跑是正常的呀。

比較了應用配置，和其他能夠正常啟動的應用也是一樣的。

就隨便看看tomcat配置吧，比較下同一臺測試機器上的兩個應用，一個是有問題的，一個是正常的。

還真不太一樣，在server.xml:

正常的：

<Host name="localhost" debug="0" appBase="/data/www/ROOT/xxx"
      unpackWARs="true" autoDeploy="false" deployOnStartup="false"
      xmlValidation="false" xmlNamespaceAware="false" >
  <Context path="" docBase="xxxxx" debug="0" reloadable="false"/>
</Host>

不正常的：

<Host name="localhost" debug="0" appBase="/data/www/ROOT/xxx"
      unpackWARs="true" autoDeploy="true" deployOnStartup="true"
      xmlValidation="false" xmlNamespaceAware="false" >
  <Context path="" docBase="xxxxx" debug="0" reloadable="false"/>
</Host>

這兩個配置不知道具體什麼含義，先改成和正常的一樣試試吧。

改了，還真就正常了，spring context只啟動一次，dubbo埠也不再被佔用。

那麼下邊來查查tomcat server.xml中，autoDeploy和deployOnStartup的含義。

摘抄：

http://www.cnblogs.com/ywl925/archive/2013/02/28/2936926.html
autoDeploy:如果此項設為true,表示Tomcat服務處於執行狀態時,能夠監測appBase下的檔案,如果有新有web應用加入進來,會自運釋出這個WEB應用
unpackWARs:如果此項設定為true,表示把WEB應用的WAR檔案先展開為開放目錄結構後再執行.如果設為false將直接執行為WAR檔案
 deployOnStartup:如果此項設為true,表示Tomcat伺服器啟動時會自動釋出appBase目錄下所有的Web應用.如果Web應用中的server.xml沒有相應的<Context>元素,將採用Tomcat預設的Context

http://kalogen.iteye.com/blog/910326

如果將autoDeploy設定為true，就會發生再次部署的現象，第一次因server.xml中的Context配置而被部署(因為deployOnstartup="true ")，

而第二次因autoDeploy被設定為true而發生自動部署(預設情況下，在沒有顯式Context的這些屬性時，它們每個的預設值都是true)。

顯式設定autoDeploy為False。避免了在server.xml中增加Context配置時兩次部署相同的Web應用程式。

先了解這一點，知道這個的存在吧。

google找到的一篇相關文章：http://www.android100.org/html/201604/23/232027.html

接下來，

應用啟動是正常了，但是在我們自己的應用管理工具上看到的應用還是沒有啟動成功。？？？

還是和正常的應用比較，應用web-inf目錄下缺少status.jsp檔案，這個檔案的內容是ok兩個字母，想想應用管理工具可能是通過訪問這個jsp檔案來測試

應用是否啟動成功的。

加上去，應用管理工具還是現實沒有啟動成功。

在瀏覽器中訪問這個jsp檔案，竟然訪問不到，這個好辦，檢查下web.xml看看有沒有被攔截就知道了。

<servlet>
    <servlet-name>springmvc</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:/META-INF/spring/security-mvc.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>springmvc</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

這總麼行，所有訪問都被springmvc攔截了。

改成

<servlet-mapping>
    <servlet-name>springmvc</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

就ok了，status.jsp就能夠正常訪問了。

那麼"/* "和 “/”這兩個url-pattern的區別是什麼呢？

以下為摘抄：

1.  寫法 ①完全匹配：以“/”開頭，以字母（非“*”）結束    如：<url-pattern>/test/list.do</url-pattern> ②目錄匹配：以“/”開頭且以“/*”結尾    如：<url-pattern>/test/*</url-pattern>    <url-pattern>/*</url-pattern> ③副檔名匹配：以“*.”開頭，以副檔名結束    如：<url-pattern>*.do</url-pattern> ④ “/” 用來表明對應的Servlet為應用預設的Servlet。在這種情況下Servlet路徑是請求的URI去掉上下文路徑並且路徑資訊為null。 2.  匹配過程 當一個請求傳送到servlet容器的時候，容器先會將請求的url減去當前應用上下文的路徑作為servlet的對映url，比如我訪問的是http://localhost/test/aaa.html，我的應用上下文是test，容器會將http://localhost/test去掉，剩下的/aaa.html部分拿來做servlet的對映匹配。這個對映匹配過程是有順序的，而且當有一個servlet匹配成功以後，就不會去理會剩下的servlet了（filter不同，後文會提到）。其匹配規則和順序如下： 1.     精確路徑匹配。例子：比如servletA 的url-pattern為 /test，servletB的url-pattern為 /* ，這個時候，如果我訪問的url為http://localhost/test ，這個時候容器就會先 進行精確路徑匹配，發現/test正好被servletA精確匹配，那麼就去呼叫servletA，也不會去理會其他的servlet了。 2.     最長路徑匹配。例子：servletA的url-pattern為/test/*，而servletB的url-pattern為/test/a/*，此時訪問http://localhost/test/a時，容器會選擇路徑最長的servlet來匹配，也就是這裡的servletB。 3.     擴充套件匹配，如果url最後一段包含擴充套件，容器將會根據擴充套件選擇合適的servlet。例子：servletA的url-pattern：*.action 4.     如果前面三條規則都沒有找到一個servlet，容器會根據url選擇對應的請求資源。如果應用定義了一個default servlet，則容器會將請求丟給default servlet

/* 匹配所有請求，自然包括/status.jsp;

/ 作為預設servlet，當應用中找不到路徑才會進來，web.xml預設會有jsp支援，根據jsp的檔名來匹配請求，那麼訪問/status.jsp能夠找到對應web-inf下邊status.jsp生成的servlet。

ok，今天這個問題是解決了。

注意點：

1.還是遇到問題，先日誌，不僅是error日誌，各個日誌都可能有幫助資訊。

2.還是google，但是要找到正確的搜尋點，比如這次遇到的問題，我搜dubbo地址被佔用相關的關鍵詞，劈天蓋地，也找不到想要的答案；在分析info日誌，

判斷出來spring context啟動兩次後（這才是真正的原因），很快能夠找到相關性大一點的網頁。