Valen Won

去年的一个项目中，我设计了一个多线程的UDP通讯程式，由我方一台主机，分别对应四地发送接收数据包。在生产环境已经非常稳健的运行了1年。
最近，随着业务的增加，连接的远端增加到了12个，也就是一个IP向12个IP发送接收数据包。
我在主线程中，管理这12个独立的通讯线程，互不干扰，由于服务器是2U4核，所以该程式的设计具有一定可伸缩性。但是，最近维护人员告诉，发现会发生某地业务停顿。一检查，线程exception terminate。居然报的是：port already bind这个最常见的exception。但是在console里面，重启这个线程，它又可以正常启动，并稳定的运行。而且它每次发生的几率很随机，有时候死掉1个，有时死掉3个，或者全部正常。
去年，该程式做过多次压力测试，并没发现这个问题，现在唯一导致它发生的原因就是线程增加了3倍。仔细分析，发现多线程的启动方式，是在spring里面进行管理和注册jmx，每个线程都事先配置成mbean。启动的时候，注入一个map里，再循环启动。而udp通讯的方式是，随机的由OS分配端口，会不会是线程的request太快，而OS没有lock port cache的strategy，我想到这里于是在循环启动bean的方法里面，加了一个Thread.sleep(100)。再次测试，解决。
最后，我认为os在分配随机端口的时候，可能没有锁定机制，如果线程的request是高conconrent，就有可能出现重叠，而引发port lready bind 这个最简单的错误。要解决这个问题，第一就是尽量延长启动间隔，尤其是多路并发的server上，第二，人为的控制port的分配。