今年真的是郁闷透顶了。项目组居然叫我去做我从来没有做过的接口方面的编程，搞得我焦头烂额。
因为没有经验，写的代码乱七八糟，出了好多问题，不过，也学了不少东西。
首先就是Socket的编程，我只是在学习JAVA时写了一些socket方面的例子，从来就没有仔细研究过，组长居然叫我设计一个JAVA的接口平台。胡弄了一通之后，系统上线了。但是问题就来了。
首先第一个问题，长连接必须有心跳。因为之前协议中没有定义心跳协议，而我又没有经验，所以等真正上线之后才发现，如果长连接没有心跳，很容易导致在Socket连接中，长时间没有通讯的话，就会导致连接虽然保持，但不能正常通讯的问题。
第二个问题，必须加入流量控制。这个问题出现在业务高峰期时，会接收到大量请求，这时业务系统的处理速度跟不上请求发起方，导致大量请求积压在Socket服务器端，导致JVM崩溃。这个问题我之前是使用了JAVA5中所带的ExecutorService，通过设置固定的线程池数量的方式做流量控制，后来发现不行，线程会不断增加，导致JVM崩溃。不知道是我代码问题还是ExecutorService本身的问题。建议使用BlockingQueue来做队列，我目前用起来还是比较稳定。
第三个问题，是由上面的问题衍生出来的一个问题，就是效率问题。我之前的线程处理方式是每接到一个请求，会在主线程实例化一个线程实例，再把线程放到线程池中运行，这个方式除了导致上面的问题以外，而且效率很慢，我称之为“推”的方式。现在经过改良后，在服务起来之后，先事先运行固定数量的线程，然后所有线程都从同一个BlockingQueue中获取指令，我称之为“拉”的方式。这种方式让程序效率提高了很多，省去了每次生成对象的过程。而且这个设计本身也实现了处理量的控制。
第四个问题，就是指令的返回问题。在处理每个异步指令的过程时，对于返回指令，通常的做法是将返回结果指令放入队列中，然后再逐一返回。这个做法就存在了一个隐患，就是当服务器的进程core掉，或者因其它原因中断，所有的返回指令都会丢失。建议的做法是在得到返回指令之后，将要返回的结果指令持久化，通常是放入数据表或者缓存文件中，然后再操作，这样的话，当重启进程，也可以重新读取返回指令，最大可能保证接口的数据准确性。
第五个问题，其实跟上面有一些接近，就是做接口程序，有一个大原则，就是一切有迹可寻。在受理时要写日志，执行业务时要记录、返回结果时要入库。总之让运维人员可以很方便的定位问题，排除问题。否则，只能麻烦自己啦！
至于其它错误我就不一一罗列了，总之在错误中进步，还是学到不少知识。呵呵～～