07 | 池化技术：如何减少频繁创建数据库连接的性能损耗？

1.老师我想请教下文中说的线程池预热，既初始化核心线程数的线程，我看jdk的源码没看到预热过程。 而且请求过来，如果线程数小于核心线程数，就创建线程处理，如果线程数大于核心线程数，就往队列中添加，如果是有界队列，则判断队列是否满了，如果满了，且线程数没有达到最大线程数就继续创建线程，是这样的流程，没有在初始化时就创建核心线程数这个数量的线程 2.如果线程池采用无界队列，确实会存在内存撑爆的问题，且最大线程数这个参数就没用了，这种队列存在有意义吗？ 3.我们工作中也用到了池化技术，线程池，各种连接池 4.我工作中遇到一个关于vertx-redis-clent的频繁fgc的问题，这个就是把请求放队列里，而队列是无界的，导致内存满了，频繁fgc，下面是我的排查过程，希望能对大家有帮助 https://mp.weixin.qq.com/s/fWsy26VeUvb8yPKON3OTmA

重要线程池的队列任务堆积量，请问下老师，这个指标怎么监控。

老师在网上查了很多的资料对于TPS和QPS两个性能指标的区分，但是也没有搞清楚到底两者有什么区别，以及两者的计算公式，老师能不能详细解释下呢？感谢。打卡06.

phper太难了

我在设计一个产品要求的专辑详情页中使用到了自定义的线程池。 专辑详情页中包含多个板块，部分几个板块要求动态请求搜索或者推荐接口获取数据，板块与板块之间要求内容去重，搜索推荐对于本系统来说属于第三方接口。 经过考量，使用了CompletableFuture来实现并行请求，同时自定义线程池，使用有界队列，设置合理的线程池大小。根据压测结果，调整出一个合适的线程池大小，使该接口性能达到预期。

刚看完丁奇老师的MySQL实战45讲，有说到“select 1 成功返回，只能说明这个库的进程还在，并不能说明主库没问题”，需要了解的同学可以去看下第29讲

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

老师，我想问下，IOC容器技术是不是相当于一个对象池，里面放着一堆创建好的对象，当你需要的时候通过依赖注入提供给你，这也算池化技术的一种应用吗

老师你的发量还好吗？

对ThreadPoolExecutor的每一个参数理解透彻很重要，曾经以为maximumPoolSize调大就可以增加线程数，其实不然，如果任务队列不满，线程数是不会增加的，所以导致任务在队列里面排队，然后线程池还是只有corePoolSize大小。