自从使用了代码扫描插件。。。

来源：5-14 使用伪异步IO改进多人聊天室

吓得我只剩头了

2019-09-15

老师，你的代码不符合阿里规范 :)
如图:
图片描述

写回答

3回答

Stannum

2019-09-22

提高代码质量标准～干得不错嘛～

当然了，咱们不能只是依赖于静态分析插件，还有更进一步理解这个规范制定的原因。

看一下源码，Executors.newFixedThreadPool()的底层实现是这样的：

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

可见，newFixedThreadPool这个factory method只是帮我们使用一些默认的参数值创建了一个ThreadPoolExecutor实例。阿里规范中所提到的风险，就隐藏在最后一个参数中。

最后这一个参数提供给线程池一个队列，当你提交一个新任务的时候，如果线程池中没有闲置可用的线程了，那么这个新任务就会被放入队列里面，等待任一一个已被占用的线程完成正在执行任务。而这个默认的队列长度是无上限的。也就是说，如果线程池中正在执行的任务长时间占用线程，而同时又不断有大量的新任务被提交，那么队列中的任务就会越来越多，直到耗尽系统资源。

如果我们不使用factory method，而是自己创建一个ThreadPoolExecutor实例，那么我们就有机会自定义这个队列的长度，以便限制线程池可能占用的系统资源。当然了，如果队列满了，可是你仍然在提交新任务，这个新任务是无法被执行的。

回到我们的聊天室例子，不管我们的线程池使用的队列是无限长或有限长的，都多多少少对聊天室的可伸展性产生了影响。使用NIO或AIO模型可以从根本性上解决这个限制。然而，即使是仍然使用BIO模型，还有没有其他的方法可以提高系统的可伸展性呢？我提供一个思路：我们是否可以强制断开长时间不发送消息的客户端，以释放线程呢？你还有什么更好的建议吗？