今天看到《如何优雅的让3个线程打印ABC》这篇文章，就像文章里讲到的，3个线程顺序打印ABC确实没有必要，很浪费，单纯考察多线程的控制机制，面稍微有点窄，也是挺鸡肋的。实际上，既要多线程并发执行，又要输出结果有序，这样的场景还真有，类似于存储系统里面的单个文件顺序存储，但是又要支持多个客户端并发写，即：多个线程并发提交IO，由一个类似于总线的机制排序，打包，按包写盘，完成后同时通知各个等待响应的客户端。这里不打算介绍复杂的IO逻辑，想拿一个简单的模型来实例解读一下。
在之前公司经常给面试者出一道题：计算 [10亿, 12亿) 范围内的质数，要求：
- 使用多线程并发计算
- 边计算边输出，按照从小到大排序输出
- 内存使用量越小越优，已知的可用内存量不足以存储所有计算结果
- 耗时越短越优
同上面的题目一样，没有华丽的算法，简单考察应试者对多线程的理解和编码能力。但这道题比上面题目要更注重实用，并不是为了多线程而多线程，并且多线程能真正起到性能提升的效果，上面的ABC只是借锁来串行化了任务执行过程，严格意义上讲，不能算是实用的多线程实例。
下面给出思路，质数计算有一定的工作量，并且随着数字越大计算量越大，题目要求的计算范围很广，因此可以简单的以数字为单位分给多个线程去运算。
尝试写了一版，发现结果队列中的记录积压严重，调整线程池的大小也无济于事。这个并发模型用得不对，用LinkedBlockingQueue仅仅解决两个线程之间的同步，可能太浪费了。take调用的开销应该太大了。
Loading ...
(4.38分 - 8票) 
(4.14分 - 7票) 
