目前遇到个场景，一个用户钱包接口，保护多个账户类型余额字段，每个字段需要单独请求结算服务查询，目前使用多线程去请求结算服务，但当请求数升高时，结算服务的响应时间会增加，应该是导致了我的线程池任务堆积，新任务提交到被执行的时间几乎等于结算的响应时间;
刚开始我想配置更多的线程数来降低任务调度时间（指任务提交到被执行的时间），但效果不明显，姑且是认为测试机的核心线程数不够，但是我有些好奇，请求结算期间，线程会让出吗？还是会一直等待，导致新任务无法被执行？
那么我想要提高qps的话，是不是最好把等待队列设为0，然后把拒绝策略改为使用主线程，然后提高最大线程数？
最后是让结算服务想办法处理高qps时的响应时间上升？
如果想观察线程池的情况以及线程在运行时的情况应该使用什么工具？
网络io应该是会让出cpu的，但是你这里的问题是，就算让出去了，你因为线程池的限制，只能实例化最大线程数的工作线程，我在想，会不会出现一种情况，此时所有的工作线程因为请求接口的问题，都让出了cpu，但是你受制于线程池的最大线程数，导致没有工作线程可以继续运行，最后的效果就是我工作队列堆积以后，只有一个结算服务的接口请求任务完结，工作线程才会去消费工作队列的任务！