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