为什么不建议直接复用其他业务的线程池？

前言最近在复查团队小伙伴的代码时发现，错误复用了一个定时触发信息同步的线程池。但他开发的代码所对应的业务场景是响应前端页面的请求。而这次的线程池复用将可能会导致系统页面“卡死” 。
信息同步的线程池，其主要配置信息为：

corePoolSize：4
maximumPoolSize：8
keepAliveTime：30L
unit：TimeUnit.SECONDS
workQueue：new ArrayBlockingQueue<>(1000)
threadFactory：new com.google.common.util.concurrent.ThreadFactoryBuilder().setNameFormat("xxx-pool-%d").build()
handler：new ThreadPoolExecutor.CallerRunsPolicy()

这个定时任务设定为每半个小时执行一次，当定时任务开始执行后，这个队列任务很快就会装满。
如果这个时候响应前端页面请求的线程进入，就会进行等待队列，此时可能会发生：

任务队列满，触发丢弃策略，前端页面请求被丢弃，用户拿不到的正确的数据；
任务较多，前端页面请求等待，可能会出现前端页面请求超时，系统“卡死”；

分析存在任务优先级存在问题。页面请求的优先级应大于信息同步任务的优先级，但如果复用同一个线程池，那么在任务执行顺序上，就是先进先执行。
如果此前已经有多个信息同步任务正在等待，页面请求也必须要等到信息同步任务执行完成以后才可以去与其他线程抢占系统资源。
结论对于一些优先级较高的任务，应当独立维护线程池。虽然在JVM中还存在线程调度问题，但至少不会一直阻塞去等待其他任务的执行。
对于一些优先级较低的定时任务，可以考虑适当复用，与此同时也需要考虑好核心线程数、最大线程数、等待队列、丢弃策略等。
【为什么不建议直接复用其他业务的线程池？】很多技术解决方案都是一把双刃剑，用得好，事半功倍，用不好，系统宕机😂