ThreadPoolExecutor多次提交同一对象的doWork方法是否可行？

你这种通过executor.execute(this::doWork)提交同一实例方法的用法完全符合Java语法规范，不需要额外单独编写实现Runnable接口的类——this::doWork方法引用本身就会自动生成符合Runnable接口要求的匿名实例，和手动写Runnable封装逻辑的效果没有本质区别。

其他需要注意的隐患（除共享字段同步外） #

• 无限循环的终止风险：doWork内的while(true)逻辑如果没有设置终止条件，会导致占用的线程池线程永远无法释放。如果需要支持优雅停机，建议新增volatile boolean running标志位作为循环判断条件，或在队列读写、HTTP调用逻辑中正确处理线程中断信号，响应InterruptedException做资源清理后退出循环。
• 线程池任务异常逃逸问题：如果doWork运行过程中抛出未捕获的RuntimeException，会直接导致当前执行任务的线程销毁，你如果没有配置线程池的自定义ThreadFactory并设置UncaughtExceptionHandler，甚至不会感知到任务异常退出，最终可能出现所有消费线程都挂掉、阻塞队列中的数据无人处理的情况。
• 共享字段的可见性风险：你提到的"操作共享字段做好同步"不仅要避免竞态条件，还要保证内存可见性。如果sharedField的读写没有通过synchronized/Lock加锁，也没有用Atomic*原子类或volatile修饰，某个线程修改了sharedField的状态后，其他线程可能长期读取到旧值，引发逻辑异常。
• OkHttpClient使用限制：OkHttpClient本身设计是线程安全的，多线程共用同一个实例发请求没有问题，但如果doWork中存在修改OkHttpClient配置的逻辑（比如动态修改超时时间、拦截器等），就会出现并发安全问题，需要额外做同步处理。
• BlockingQueue复合操作风险：BlockingQueue的单个操作（比如take()/put()）是线程安全的，但如果存在复合操作（比如先peek()判断元素符合条件再take()），这类操作不具备原子性，还是会出现竞态条件，需要额外加锁保证原子性。
• 线程池配置适配问题：两个doWork任务都是长期运行的常驻任务，需要保证你的ThreadPoolExecutor核心线程数至少大于等于2，否则会出现任务长期排队无法执行的问题；同时如果doWork中HTTP调用占比较高属于IO密集型任务，需要合理调整线程池最大线程数，避免吞吐量过低。

内容的提问来源于stack exchange，提问作者Arzybek