最近在阿里云買了一臺輕量應用服務器，但在部署Tomcat啟動服務之后，瀏覽器訪問http://[公網IP]:8080時遲遲訪問不到，于是我開始了漫長的除錯之路，

正常情況

1.保證阿里云安全組開啟了8080埠

2.保證Linux防火墻放行8080埠

# 查看firewall服務狀態
systemctl status firewalld

# 開啟、重啟、關閉、firewalld.service服務
# 開啟
service firewalld start
# 重啟
service firewalld restart
# 關閉
service firewalld stop

# 查看防火墻規則
firewall-cmd --list-all    # 查看全部資訊
firewall-cmd --list-ports  # 只看埠資訊

# 開啟埠
開埠命令：firewall-cmd --zone=public --add-port=8080/tcp --permanent
重啟防火墻：systemctl restart firewalld.service

命令含義：
--zone #作用域
--add-port=80/tcp  #添加埠，格式為：埠/通訊協議
--permanent   #永久生效，沒有此引數重啟后失效

#查看埠是否正常監聽
netstat -an | grep 8080
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN     

正常情況下，到這里，啟動Tomcat服務，瀏覽器就可以訪問了，但哪有那么多正常情況，

非正常情況

1.遇到問題

我來詳細說下我遇到的問題：

1. 打開Tomcat服務后，瀏覽器訪問不了，一直轉圈圈~

2. 就在這時我想關閉服務重啟，問題來了

   SEVERE: Could not contact localhost:8005. Tomcat may not be running.
   SEVERE: Catalina.stop: 
   java.net.ConnectException: Connection refused
           at java.net.PlainSocketImpl.socketConnect(Native Method)
           at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
           at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
           at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
           at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
           at java.net.Socket.connect(Socket.java:579)
           at java.net.Socket.connect(Socket.java:528)
           at java.net.Socket.<init>(Socket.java:425)
           at java.net.Socket.<init>(Socket.java:208)
           at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:450)
           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:606)
           at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:400)
   
           at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:487)
   

2.找到原因

這里找到原因了，SEVERE: Could not contact localhost:8005. Tomcat may not be running.

也就是說，Tomcat服務還沒有啟動，那么這個時候我去停止也是停止不了的，那它為什么沒有啟動還沒有報錯呢？？

這里其實是不準確的，是因為我們在Tomcat沒完全啟動前就關閉Tomcat，

那么既然沒報錯，說明服務啟動會成功，那我就等著你成功！

等了6分鐘，終于等到你！

3.探究原理

那么現在也就是說，我們操作沒毛病，只是這個服務啟動的太慢了，

可，為什么這么慢嘞？？？

我查看了一下行程，Tomcat所在的JVM行程已經被啟動了所以可以排除是JVM退出引起的問題，那么問題真的就是JVM因為某種原因被阻塞了，

分析

程式被阻塞一般來說一定是要等待某個資源，而現在的情況是所有資源都充足，仔細想想我需要找到Tomcat停止在了哪里？代碼里發生了什么事情，我決定試一下 strace，這是一個跟蹤系統呼叫(System Call)的工具，無論是Java還是Pyhton很多資源申請都會變成System Call，（比如打開檔案、新建執行緒、讀寫資料、等待I/O）通過這個工具我至少可以知道Tomcat是停止在哪個System Call上的，這樣可以方便我推斷出問題的原因，

在我尋找問題的時候，他又啟動好了，所以我們先把它關閉，

./shutup.sh

然后進行跟蹤

strace -f -o strace.out ./catalina.sh run

strace有很多引數，我用了兩個引數

• -f 跟蹤fork的子行程，通俗的說會跟蹤所有執行緒的系統呼叫
• -o把內容輸出到檔案

這一步結束后我們來看看結果，

cat strace.out

分析的方法是從下往上（被阻塞的地方肯定是在最后咯），首先我們需要去掉Tomcat停止引起的System Call，它們不是我們需要的，從后往前搜索找到SIGINT，

紅色部分以上就是引起阻塞的系統呼叫了，上面有一大堆一大堆的futex的呼叫，它們是Linux中的一種輕量級的同步方法，所以我們可以判斷出最上面肯定是有某個System Call就是阻塞的真正元兇，跳過所有的futex：

這個read就是引起后面一串futex的真正原因，strace非常聰明它不僅僅給出了System Call還給出了傳遞的引數和回傳值，read讀取的是61號檔案句柄，沒有回傳成功(unfinished)，

順著這條路，我們看一下61號檔案句柄是什么：

/dev/random是Linux下的隨機函式生成器，讀取它相當于生成亂數字，

搜索它，簡單來說就是，/dev/random的亂數生成依賴系統環境噪聲，如滑鼠、鍵盤操作等，
當噪聲資料不夠的時候，就會出現讀取阻塞，

深入分析

如果用Tomcat /dev/random作為關鍵字基本上就能夠回答我們的疑惑了，Tocmat的Session ID是通過SHA1演算法計算得到的，計算Session ID的時候必須有一個密鑰，為了提高安全性Tomcat在啟動的時候會通過隨機生成一個密鑰，這個亂數是通過 linux的提供的隨機函式生成器提供永不為空的隨機位元組資料流，許多加密解密程式需要用到它們提供的亂數，

解決問題

明白了問題的原因解決起來就非常簡單了——替換/dev/random為/dev/./urandom，用偽隨機函式生成器(/dev/./urandom)來替代隨機函式生成器(/dev/random)，

• 通過修改Tomcat啟動檔案catalina.sh
  –Djava.security.egd=file:/dev/./urandom
• 通過修改JRE中的java.security檔案securerandom.source=file:/dev/./urandom

4.徹底解決問題

在Linux（CentOS）環境下，亂數可以從兩個特殊的檔案中產生，一個是/dev/urandom，另外一個是/dev/random，

它們產生亂數的原理是利用當前系統的熵池來計算出固定一定數量的隨機位元，然后將這些位元作為位元組流回傳，熵池就是當前系統的環境噪音，熵指的是一個系統的混亂程度，系統噪音可以通過很多引數來評估，如記憶體的使用，檔案的使用量，不同型別的行程數量等等，

上面介紹的兩種方式都是用/dev/urandom替換/dev/random，其實還有第三種方式——增大/dev/random的熵池，問題的原因是由于熵池不夠大，所以增大它是最徹底的方法，

通過以下命令，我們可以查看現在的熵池大小；

cat /proc/sys/kernel/random/entropy_avail
189

我們需要找到一種方式來提高這個值就行了，如果你的CPU帶有DRNG特性，可以充分利用硬體來提高熵池產生的速度 ，

通過cat /proc/cpuinfo | grep rdrand可以查看自己的CPU是否支持，一般來說Intel的Ivy_Bridge架構的CPU都支持（i3、i5需要注意是否采用該種架構，i7和xeon基本上都支持）；AMD的CPU在2015年以后生成的都支持，（如果你是虛擬機需要開啟額外的引數)，如果你的硬體不支持，也沒有關系，我們可以讓/dev/urandom來做“熵源”，

以Centos7為例，

• yum install rngd-tools(或者rng-tools)安裝rngd服務（熵服務）

• systemctl start rngd啟動服務（支持DRNG特性的同學，到這里就可以cat /proc/sys/kernel/random/entropy_avail查看了）

  cat /proc/sys/kernel/random/entropy_avail
  3009
  

• 如果你的CPU不支持DRNG特性，可以使用/dev/unrandom來模擬，

• cp /usr/lib/systemd/system/rngd.service /etc/systemd/system

• vim /etc/systemd/system/rngd.service

• ExecStart=/sbin/rngd -f -r /dev/urandom

• systemctl daemon-reload重新載入服務

• systemctl restart rngd重啟服務

5.選擇哪種解決方法

個人建議選擇第三種方式，熵池不僅僅Tomcat用，Linux下的所有應用程式產生亂數都會用到這個，所以不僅僅是Tomcat可能被阻塞，如果你搜索會發現Apache、Nginx、OpenSSL都被這個問題坑過，如果我們通過修改Java的配置來解決這個問題其實只是解決Java應用程式的問題，只能是治標不治本，根治的方法應該是通過rngd提高亂數生成的速度，

6.如何重現故障

可以很容易的重現上面描述的故障

• systemctl stop rngd 停止rngd服務（如果你有啟動rngd）
• 查看當前熵池的大小cat /proc/sys/kernel/random/entropy_avail
• head -c1024 /dev/random，強制消費1024個亂數，系統會長時間沒有反應，直接ctrl+c
• 再次查看熵池的大小cat /proc/sys/kernel/random/entropy_avail，保證它的大小在盡可能的小
• 啟動tomcat，會發現又是很長時間的等待