今天尝试使用Selector改造转发逻辑,结果可耻的失败了!由于Selector不是线程安全的,试图多个线程进行register会致使严重的问题,这也是为何基于事件的IO模型都不怎么支持多线程的缘由,太难作了。缓存
后来尝试用Java的Future机制来实现超时。咱们知道,Java的FutureTask须要一个执行的线程池。若是每次都new出来固然没有问题,可是经测试性能开销较大(qps被降到了4000)。后来尝试复用同一大线程池,发现请求多了以后,老是会超时!安全
而后jstack查看发现,不少线程仍然卡在了Callable.call方法,就是咱们常说的异常把线程抛死了!原来TimeoutException也会致使线程抛出异常可是没法回收。解决方法:使用future.cancel()。多线程
这也说明,线程抛出异常死掉时,jstack查看到的是它抛出异常时的执行栈。架构
加入超时机制后,程序算是稳定了,这周末弄个1.0版吧,之后开始写ReleaseNotes。函数
今天看了一下代码,做为一个开源项目,彷佛风格不是那么优雅,不少长函数,注释也不完整。顶多对架构和原理感兴趣,代码的OOP神马的,这方面彻底提不起兴趣来啊。性能
在本身的MBP上也编译了一个queryperf,测试性能达到55000qps,而拦截模式只有35000,果真仍是缓存byte[]更给力啊。所以把拦截模式也加入了cache。测试