#20191101更新---這篇文章適用於產生僵屍文件的進程是可kill的狀態參考,就是這個進程死亡不影響業務，那么另外一種情況，也是我現在管理的項目中生產環境中出現過的情況，產生僵屍文件的進程是webapp應用，不能被kill，kill后，將會影響生產環境業務，但是磁盤也已經滿了，那么可以參考此種另一篇文章處理（不影響進程的情況下清理系統空間):
https://www.cnblogs.com/xiaodai12138/p/11102660.html
今天在工作中遇到一個小問題，剛處理好了，趕緊把解決思路存起來。
入職新公司1個月多了，對整體的項目不能說是完全熟悉，今天收到短信說服務器的硬盤空間不足了。
異常的時候忘記截圖了，處理完畢后又找不到異常時候的資源占用狀態，這是講系統盤處理完畢后的狀態，異常時系統盤占用率高達96%
我發現磁盤空間不足后，剛開始的思路是到/下通過du -sh 來查找大文件，刪了幾個備份文件和一些沒用的日志記錄之后，雖然可以將占用降到80%左右，但是還是挺高的（紅框是nfs掛載）
除去nfs掛載的文件，其余文件怎么可能將20G占用的所剩無幾呢
得知這個方案不可行后，考慮了其他查詢方案，看是否有狀態為delete的文件
(僵死文件。這些文件實際上已經被刪除，但是有服務程序在使用這些文件，導致這些文件一直被占用，無法釋放磁盤空間，使用如下命令可以查看死文件占用情況）
lsof |grep deleted //在opt目錄下執行lsof |grep deleted
如附件，表紅區域為這個僵死文件的大小（單位為字節Bytes）。
當時在這里我可以看到幾個很大的文件是delete狀態，一下就點通了我。
就在准備kill掉他的時候，又出現一個問題，delete狀態的文件最終指向一個端口監聽，並且有幾十個已建立的連接，我不知道這個端口的作用，通過ps命令看到這個端口的進程id，跟一個項目是有關聯的，但是這個項目已經停止使用了，且早就被我shutdown了。
這個端口監聽我死活找不到是哪個項目監聽的這個端口，由於是項目不是完全熟悉了，不知道這是什么個情況，起初還以為有其他的項目使用着這個項目的配置文件啥的，但是想了想有不太可能，跟之前運維確定了沒有過這個端口的使用后，就將其kill了，kill后，系統盤占用立馬恢復正常，恢復到了開頭的那個狀態，這個情況可能是tomcat的某些bug導致，雖然項目停止，但是連接還是建立着，這個項目停止了有幾天了，這些已建立的連接還是已建立（難道client端不發送連接斷開請求，不關機嗎）。。
由於tomcat內部機制並不了解，這個話題就到此結束。
這樣起來處理數據盤資源占用就輕松多了
占用數據盤資源的是一個運行中的jar包，這個jar包以nohup形式運行，之前運維沒有關閉nohup.out的輸出導致出現了這么大的僵死文件。
我的做法是將其kill后再次啟動，將結果送到回收站，以后可以避免出現這些問題。
nohup java -jar SocketServer.jar >/dev/null 2>&1 &
>/dev/null 表示將標准輸出信息重定向到"黑洞"
2>&1 表示將標准錯誤重定向到標准輸出(由於標准輸出已經定向到“黑洞”了，即：標准輸出此時也是"黑洞"，再將標准錯誤輸出定向到標准輸出，相當於錯誤輸出也被定向至“黑洞”)
完后問題解決完畢，磁盤占用恢復正常。
