使用JAVA编写报文接收端的注意事项

使用JAVA编写报文接收端的注意事项

在JAVA中编写报文服务端，是非常简单的事情，因为JAVA已经为我们封装了TCP/IP这些东西，我们不需要去关注这些；它对我们提供了方便操作的ServerSocket类，如果不考虑其它因素，那么要启动一个服务端，只需要简简单的几句代码：

//以下启服务端，其中6500表示用于侦听客户端连接的端口

ServerSocket serverSocket=new ServerSocket(6500);

while(true){

Socket socket=serverSocket.accept();

if(socket!=null){

System.out.println("有客户端连接过来");

//下面对客户端做相应的动作，这里省略

}

}

从上面可以看出，我们根据没有去管理那些协议去怎么样实现，走的七层网络协议还是四层网络协议，这些对我们来说都可以暂时不去管。但是，这种东西只能说你看到了希望（没有像现在的中小学奥数班一样，在你一开始的时候就让你对学习失去兴趣）、有了信心，后面要做什么事情，就是在现在的基础之上扩充，使苦适合于真实的环境中，就像大家经常说的一句话一样：社会，是现实的。我们还需要考虑以下方式的事情：

1、正确性与精确性。这句话是从软件工程上学来了，因为不管是做什么软件，写什么代码，如果连正确都谈不上，那这个东西存在的意义也不大。这里就是要能够正确处理客户过来的请求，不要将客户查询的请求搞成了更新或者是删除，那后果可就严重了，所以这是第一个要注意的。

2、性能与效率。当你写的代码能够做正确的工作的时候，不管是一分钟完成还是十分钟完成，再甚者N个小时，只要是正确的，客户都可以接受，当然你得给客户N个多可以接受的理由，如：查询的时候要关联很多表，数据量太大，计算的时间比较久，就如我现在这边的全行日终跑报表系统，客户几个小时都可以接受。但是我们不能够满足于这样，我们是程序员，在可能的情况下让自己写的东西跑得更快，而不仅限于跑得完就是了，就像马拉松，人人都可以跑，就算不得冠军也不要搞个最后一名吗！其中有一块特别需要优化的就是要采用连接池替代单一的“请求-连接”模式，成熟的、开源的、稳定的连接池网上很多，比较常用的有APACHE的DBCP、W3C的C3P0、Hibernate自带的连接池等等，性能都还不错，这样可以节省系统资源与加快运行速度。

3、能够处理的最大并发数。这时就要采用线程池的方式，不要来一个请求就新启动一个线程，这样请求越多，要求生成的线程数也越多，达不到调节系统资源的目的；采用线程池可以自动调节，如果请求少的情况，就少生成连接数，如果多的情况下就多生成，再如果超过了最大的连接数，那让就他们等到有空了再说；这同做生意一样，桌子板凳都没有了，就只有等到别人吃完了。JDK自1.5开始就自带有连接池，需要我们关心的东西，只需要调用的时候设置向个参数，如最小连接数、最大连接数、线程的生存时间及单位等，它会帮忙管理 与调用线程，以保证系统性能的最大化，启动调用和单独采用Thread启动线程没有什么区别。最简单下面两句代码就OK：

ThreadPoolExecutor threadPool = new ThreadPoolExecutor(5, 50, 3,TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(10),new ThreadPoolExecutor.DiscardOldestPolicy());

threadPool.execute(new MsgListener(clientSocket));

4、代码不一定要自己写。没错，能够不自己写的就最好不要写，因为代码是写的越多错的机会越多，并且还要花时间去调式，有够用现成的工具，如上面的线程池、连接池等等，都可以说是比较优秀的，因为他们都经过时间的检验，写这些代码的都是比较高的人，我们完全可以信赖。如果要对数据进行操作，我的方式是先用POWERDESIGNER做CDM，把关系都理好了，再生成PDM，然后写到库，然后再通过HIBERNATE的MIDDLEGEN工具，生成Hibernate映射文件，再通过Hibernate的HBM2JAVA，再生成基础的代码，这样你可以省去不少的时间，并且可以保证性，然后你再写关注自己业务方面的东西，开发起来又快又稳。

5、保证客户端过来的请求都能够被处理。请算你采用连接池，但有些时候遇到连接确定太忙，数据库服务忙不过来，这个时候去数据库操作，如你要将客户端过来的报文写到库中保存，但是HIBERNATE给你报过"Can't Open Connection"，那你的这表交易就不处理了吗？不可能，这是金融系统，由人行的发过来的，你以为它还等你说，如果失败次数超过了规定了，那就等着挨批吧。所以这个时候就算没有成功，也要说我成功了，后面再把失败的给做进去。我这里采用将失败的即发生异常的交易的报文全部放到XML中，然后再通过线程定时去检测并处理，这样就可能保证只要是接到了的请求，在线程池没有严重超标的情况下，所有的请求都可以被处理；为什么说没有严重超标呢，因为如果线程池超时过久，就会被线程池给KILL掉，所以请求就莫明其妙的没有了，但也不能够将线程的生存周期设置太久，否则这样也不利用其它线程的处理，会导致更大的问题。

6、参数配置化。尽量将需要用到的变更，与客户环境有关的，都做成参数化，这样就不需要我们再去修改程序了。

7、多做测试。在完成某个功能，或者是某个模块的时候，一定要测试，否则等到后面来一运行，什么问题都一下子出来了，找问题都不知道从什么时候找起。边做边测试，这是只有好处没有坏处的。如这里你一定要有客户端，去测试你的服务端，测试并发的性能与处理的结果的正确性与快速性等。

本文出自：冯立彬的博客