現象：服務器跑了兩天左右，出現了兩種情況 ：
1.內存溢出
2.內存沒有溢出，但是提供不了任何服務，服務器不能接收任何request
分析：
1.擴大虛擬機的內存，結果服務器跑長了點時間，照樣內存溢出
2.Dump出Heap快照，並用Eclispse Memory Analyzer進行分析，發現RTMPMinaConnection對象大量存在ConcurrentHashMap對象裏面，為什麽會出現大量的connnection？即使是大量的客戶端請求，為什麽內存沒有釋放？
3.分為三個問題考慮：
1)為什麽會出現大量的connnection？連接從哪裏來的
2)大量的connection為什麽會沒有釋放？
3)為什麽connection達到壹定的數量，服務器即使在內存充裕的情況下，仍然提供不了任何服務？
根據大量的觀測，發現red5 服務器，我們用Haproxy代理了rtmp請求，而HA即使沒有請求的情況下，仍然試圖連接，以探測代理的服務器是否存活，而red5的keepalive時間壹過，會試圖關閉連接，關閉之後，通過查看源代碼發現，connection雖然關閉了，但是沒有從concurrentHashupMap裏面remove掉，而真是這種Ha的不停的通過創建心跳連接來探測red5是否處於活的狀態，而red5關閉連接之後，並沒有從concurrentHashMap裏面移除，從而造成了最終的內存溢出，同時由於沒有移除inactive的連接達到了red5設定的最大的允許的inactivity連接的數量，默認為60000個連接，從而造成我們剛才看到的現象-即使內存充裕的情況下，仍然提供不了任何服務的情況。
查找這個錯誤的過程是痛苦的，甚至沒有壹點頭緒，還好通過大量的測試和源代碼分析，發現了這個問題。我們現在已經升級到red5 0.9.1的版本了，目前情況良好，同時為了確保服務器的穩定性，我們也查閱了相關的源代碼，可以確定0.9.1版本中已經fix了這個問題。相信red5 server在我們的產品上線後會處於非常穩定的狀態。
發現這個問題，壹些工具的使用是關鍵的：
首先，要會分析heap快照，而eclipse memory analyzer確實是很強大的工具。幫我們提供了大量有用的信息。
其次，開源軟件是不可靠的，只有我們對它們的代碼有深入的分析才會得出好的結果。還好，源代碼開放也為我們提供了查找問題來龍去脈的根據。而我們也可以對開源軟件進行優化，在以後的內容裏，我也會記錄我們優化red5 server的整個過程，相信還有很多地方，我們仍然可以優化它。
網上找的~~