Web服务中使用线程池是提高了性能还是限制了性能问题？
- 创建一个Web服务，比如一个：SpringBoot微服务。
- SpringBoot服务中定义一个线程池，核心线程数20个，最大线程数也是20个。
- 对外暴露一个API接口，接口功能是需要循环60次到数据库获取数据（不要说让改这个查询逻辑），并且合并返回。
此时，为了提高服务器性能，加快返回的时间，现在将查询数据库的操作提交给线程池处理，那么相当于说：当有一个request进来的时候，原本需要循环60次才能拿到的结果集，现在有20个线程在同时查询，性能提高了20倍（理论上）。
但是，如果现在我有100个并发，也就是说有100个请求同时进来，那么这个线程池是怎么工作的呢？
- 是同一个时间段只有20个线程在连接数据库查询呢？
- 还是有100 * 20 = 2000个在连接数据库查询呢？
如果是第一种情况，那么是不是限制了服务器运行，降低了性能呢。甚至，因为请求并发提交给线程池处理数据，有可能造成第一个请求要等最后一个请求执行的差不多的时候才能拿到结果。严重影响性能。
如果是第二种情况，那么进程中的线程数量将暴增，有可能硬件设置也是无法承受的。
我猜测是第一种情况，一会要按照上面的步骤写一个demo试试，现在先把问题提出来，大家一起讨论一下。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要具体问题具体分析. 线程池免去了创建线程的开销, 肯定是提高性能了.
我们的目标是最大程度压榨机器性能, 又不能让机器挂掉.
又多少个线程完全看你怎么写，如果你线程池公用，那么无论你多少个用户请求，就只有20个线程。如果你每个用户创建一个线程池，那就会有很多个线程。线程并不是越多越好，要看是IO密集性还是计算密集型。你这种确实属于IO密集性，但最合适的线程数是通过压测得来的，也得看CPU是几核的，大致的话是有公式参考的
CPU 核心数 * (1 + IO 耗时/ CPU 耗时)。不推荐每一个用户创建一个线程池，这是在埋雷。借楼 问个问题; 微服务种. java 内部异步任务走线程池的还多吗?
万一进程挂掉,那些任务也挂了找不回了.
还是全部走 mq形式.
我们app也就30w DAU. 只有少数一些无关紧要(丢了也就那样)的任务,直接扔内部线程池了.