我在设计一个产品要求的专辑详情页中使用到了自定义的线程池。

专辑详情页中包含多个板块，部分几个板块要求动态请求搜索或者推荐接口获取数据，板块与板块之间要求内容去重，搜索推荐对于本系统来说属于第三方接口。

经过考量，使用了CompletableFuture来实现并行请求，同时自定义线程池，使用有界队列，设置合理的线程池大小。根据压测结果，调整出一个合适的线程池大小，使该接口性能达到预期。

1.先回答课后题，池化的应用。池化就是空间换时间。万物皆对象，而java里面的对象是有生命周期的。对象的生死对应着有生时资源申请和死时资源释放这两步操作，而这些操作是有时间开销的。这个时候如果想降低这些开销，那么就要少生对象少死对象，而要少生少死就得复用，即干完继续干不准死，即延长对象生命周期并重用之。那么就可以采用池化，用的时候往里面拿，用完放回去。所以就出现了对象池，而对象即万物。也就是说，只要你是想降低对象生死开销的，那么就可以采用池化。但于我个人，我不喜欢池化。
2.我个人认为，池化仅用在线程池好点。其他都不咋地。因为线程是执行体本身，所以挺合适。其他池化操作，都属于资源，那么复用就要无状态，即拿出来和放回去要一个样，不然就会影响下一个人使用（下一个线程），那么在操作池化对象时要么得设计无状态要么得在归还或拿取做init操作，太麻烦，不直观，不喜。而且池化资源还是个竞量，这就是个提高复杂度的大坑，太糟糕了，弃了弃了。
3.说归说，其实用还是用的，毕竟也不全是jvm内部的“干净”对象池，有些对象池跟jvm外部资源有关系“不干净”。这种不干净的对象池，采用池化按需配置也是比较恰当的操作，毕竟外部关系这种开销大小不好确定，比如各种连接池。
4.但我个人做的工具，碰到这种空间换时间，随手就是线程空间绑定，虽然还有复用无状态的问题，但至少不担心竞量问题了。而各种数据链接池，如果开启了事务也是往线程空间内放该链接的（为了拿到同一条链接）。

5.请教环节，系统的线程池我自己埋点压过，确如老师所说，cpu密集线程池看核数就够了，io密集可以多些并行，因为数据传输不需要cpu。但是，从我自己压，捣鼓出来的结果看。io操作的线程确实可以在不处于cpu操作的时间片内时，继续做数据传输，但是，它不让渡时间片，也就是当一个cpu调度到一个执行io操作的线程，这条线程不会快速让渡出时间片给其他cpu操作的线程，就像sleep似的。我想问下老师，为什么这样设计，出于什么考量，更或者是我自己捣鼓错了？