一、問題由來
現在的項目中在使用webSocket這門技術，主要用來在服務端和客戶端進行實時的數據傳輸，因為需要及時的進行響應，所以才沒有使用http請求的方式，
而是使用socket的方式，這樣可以快速建立起連接，並且能夠將小程序端的操作實時的在客戶端unity程序中進行響應。最開始做這個項目的時候，自己對
於技術選型這一塊，就考慮使用webSocket，經常會在各種博客、論壇中看到關於它的介紹和使用。而且給人的感覺不是太難，因此就打算使用它。客戶端
程序主要是unity程序來進行處理，會和java寫的服務端進行實時通信傳輸很多數據，在剛開始測試的階段我們都不知道這種方案能不能行得通，在經過多次
反復地測試之后，發現這種方式可行，最終采用這門技術應用於現在的系統當中。可是后來在使用的過程中出現一個問題，就是當webSocket運行出現異常，
比如客戶端和服務端的連接由於網絡不好斷開之后，當網絡恢復正常再次進行連接時就會頻繁報錯，
報錯信息是客戶端發送的心跳包數據，由於客戶端不知道服務端已經出現問題，因此頻繁的發送心跳包就一直報錯。
二、問題分析
自己在寫服務端時，當運行onError方法時，會清除一個唯一的webSocket連接，由於這個項目的特殊性，只需要始終讓服務端和客戶端保持有一個有效的連接
即可。自己的想法是，明明已經清楚了服務端唯一的連接，為什么還會出現這種問題呢？
這個問題隔三差五的就會出現，必須要解決，如果不解決的話肯定會影響項目的正常運行。
三、解決方案
進過對問題的仔細分析后，自己嘗試着去解決這個問題，一個一個地進行嘗試。
方案一:在運行出錯的時候，主動調用webSocket中提供的關閉連接的方法，使用this來進行調用。
測試結果，沒有解決。
方案二：在運行出錯的時候，主動獲取集合里面的那個唯一的webSockerServer對象，然后使用這個對象來調用onClose方法，並且關閉當前的連接
會話session。
代碼修改好之后，和客戶端進行反復的聯調測試，發現問題解決。解決這個問題的思路就是，如果服務端運行出現異常，就在服務端主動
關閉這個連接；當這個連接關閉之后，當客戶端和服務端想再次進行通信時，就會重新創建一個新的連接，保重系統的正常運行。
至此問題解決，可能也是這個項目的特殊性才導致這個項目只需要有一個唯一的連接就可以，遇到的問題也比較好解決。總結一下就是如果
服務端想關閉掉某個連接，則最好是先找到這個webSocket這個連接，然后關閉即可，還有關閉當前的會話信息，不能使用集合直接清除，
直接清除結合的話，webSocketServer是清除了，可是連接會話信息卻還在，因此導致我出現那個問題。