首先說一說問題的背景：

服務器端采用tomcat為J2EE容器，在一次失敗的NIO測試（把控制臺輸出信息寫在了NIO阻塞用的循環中）後，Ubuntu系統幾乎崩潰，關閉java相關進城後，tomcat無法再次啟動，我就采取了互聯網人民最厲害的招數-重啟服務器。
在重啟服務器之後，tomcat可以啟動，但是獲取不到JDBC連接了，顯而易見，這是MySQL沒啟動，正當我準備開啟MySQL服務的時候，出現了下面的顯示
：

在種種排查之後，就像端口占用、相關配置文件，在通過文件啟動MySQL服務的時候，報錯信息變得清晰了

通過查看，所說目錄的大小並不像ERROR中說的那樣，再次查看Ubuntu的硬盤容量，發現占用率幾乎到了100%：

在網上找了很多方法之後，我也覺得只有日誌文件才會發生在短時間內增大的可能，於是準備刪除與MySQL相關的日誌文件（狠下心直接刪除了整個/var/log）：

可以看到，我們的問題還是沒有解決，那麽問題到底出在了哪裏？

回憶問題發生的整個過程，源頭是在J2EE項目一段錯誤的代碼，雅思托福怎麽考會不會是tomcat產生的日誌文件突然增大以至於占滿了整個Ubuntu硬盤：來吧，刪除

至此我們刪除了和今天有關的所有tomcat日誌文件（其實是沒必要的，但是由於沒有什麽必須數據），同時也手動清空了catalina.out中的所有內容，至此 我們又查看硬盤容量情況，嘗試再次啟動MySQL服務：

至此，問題解決了，MySQL在檢查日誌文件預留空間時，會因為整個磁盤的大小而被限制，而報錯的時候不可能精確的找出是哪裏出了問題，畢竟萬一是你自己真的把空間用完了呢。報錯雖然是MySQL給的，但是tomcat才是真正的幕後兇手。

通過這次報錯，我們可以發現，有時錯誤產生的結果並不是真正的原因，但是其中必定存在著種種聯系，學會透過現象看本質才是真的解決方案，同時，學英語還是有用的。至少你能看懂報錯信息。

解決方案：對於NIO的難以控制，業界有目共睹，所以果斷轉行Netty取而代之，對於tomcat日誌文件的無限增長，我們可以通過檢測，在日誌文件異常時通過dump或終止服務器輸出來防止空間利用率接近100%

mysql job failed to start-tomcat問題變種