今年真的是郁悶透頂了。項目組居然叫我去做我從來沒有做過的接口方面的編程，搞得我焦頭爛額。
因為沒有經(jīng)驗，寫的代碼亂七八糟，出了好多問題，不過，也學(xué)了不少東西。
首先就是Socket的編程，我只是在學(xué)習(xí)JAVA時寫了一些socket方面的例子，從來就沒有仔細研究過，組長居然叫我設(shè)計一個JAVA的接口平臺。胡弄了一通之后，系統(tǒng)上線了。但是問題就來了。
首先第一個問題，長連接必須有心跳。因為之前協(xié)議中沒有定義心跳協(xié)議，而我又沒有經(jīng)驗，所以等真正上線之后才發(fā)現(xiàn)，如果長連接沒有心跳，很容易導(dǎo)致在Socket連接中，長時間沒有通訊的話，就會導(dǎo)致連接雖然保持，但不能正常通訊的問題。
第二個問題，必須加入流量控制。這個問題出現(xiàn)在業(yè)務(wù)高峰期時，會接收到大量請求，這時業(yè)務(wù)系統(tǒng)的處理速度跟不上請求發(fā)起方，導(dǎo)致大量請求積壓在Socket服務(wù)器端，導(dǎo)致JVM崩潰。這個問題我之前是使用了JAVA5中所帶的ExecutorService，通過設(shè)置固定的線程池數(shù)量的方式做流量控制，后來發(fā)現(xiàn)不行，線程會不斷增加，導(dǎo)致JVM崩潰。不知道是我代碼問題還是ExecutorService本身的問題。建議使用BlockingQueue來做隊列，我目前用起來還是比較穩(wěn)定。
第三個問題，是由上面的問題衍生出來的一個問題，就是效率問題。我之前的線程處理方式是每接到一個請求，會在主線程實例化一個線程實例，再把線程放到線程池中運行，這個方式除了導(dǎo)致上面的問題以外，而且效率很慢，我稱之為“推”的方式。現(xiàn)在經(jīng)過改良后，在服務(wù)起來之后，先事先運行固定數(shù)量的線程，然后所有線程都從同一個BlockingQueue中獲取指令，我稱之為“拉”的方式。這種方式讓程序效率提高了很多，省去了每次生成對象的過程。而且這個設(shè)計本身也實現(xiàn)了處理量的控制。
第四個問題，就是指令的返回問題。在處理每個異步指令的過程時，對于返回指令，通常的做法是將返回結(jié)果指令放入隊列中，然后再逐一返回。這個做法就存在了一個隱患，就是當服務(wù)器的進程core掉，或者因其它原因中斷，所有的返回指令都會丟失。建議的做法是在得到返回指令之后，將要返回的結(jié)果指令持久化，通常是放入數(shù)據(jù)表或者緩存文件中，然后再操作，這樣的話，當重啟進程，也可以重新讀取返回指令，最大可能保證接口的數(shù)據(jù)準確性。
第五個問題，其實跟上面有一些接近，就是做接口程序，有一個大原則，就是一切有跡可尋。在受理時要寫日志，執(zhí)行業(yè)務(wù)時要記錄、返回結(jié)果時要入庫。總之讓運維人員可以很方便的定位問題，排除問題。否則，只能麻煩自己啦！
至于其它錯誤我就不一一羅列了，總之在錯誤中進步，還是學(xué)到不少知識。呵呵～～