Java线程池任务“丢失”实为拒绝策略静默丢弃所致：DiscardPolicy/DiscardOldestPolicy不报错不记录，AbortPolicy异常未捕获亦致任务不执行；需结合队列监控、日志增强与动态调参防丢。
Java线程池本身不会“随机丢失”任务，但当队列满 + 线程数已达 maximumPoolSize 时，新提交的任务会触发拒绝策略——此时若策略是 DiscardPolicy 或 DiscardOldestPolicy，任务就真的不执行、不报错、无声无息地“消失”了。
为什么任务看起来“丢了”：拒绝策略默认静默丢弃
这是最常被忽略的根源。ThreadPoolExecutor 默认构造的线程池（如 Executors.newFixedThreadPool()）底层使用的是 AbortPolicy，它会抛出 RejectedExecutionException；但很多自定义线程池显式传入 new ThreadPoolExecutor.DiscardPolicy()，而这个策略什么也不做——run() 方法直接 return。
-
DiscardPolicy：不抛异常、不记录、不重试，任务对象被 GC 回收，就像没提交过 -
DiscardOldestPolicy：丢掉队列头任务，再尝试提交当前任务——旧任务丢了，且无日志提示 - 即使用了
AbortPolicy，如果调用方没捕获RejectedExecutionException，异常可能被吞掉，结果仍是“任务没执行”
如何确认是不是真丢了：看队列容量和拒绝日志
别只盯着代码里有没有 submit()，重点查运行时状态和拒绝路径：
- 检查队列类型：
LinkedBlockingQueue默认容量是Integer.MAX_VALUE，看似不会满，但实际会导致线程池永远不扩容到maximumPoolSize，高并发下任务全堆在队列里，OOM 风险远大于丢任务 - 用
executor.getQueue().size()和executor.getActiveCount()在监控端点中定期采样，确认是否长期接近队列上限 - 给自定义拒绝策略加日志：
new RejectedExecutionHandler() { public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { log.warn("Task rejected: {}, queue size: {}", r, e.getQueue().size()); } }
真正防丢的 3 种务实做法
不是换策略就万事大吉，得结合场景闭环：
立即学习“Java免费学习笔记（深入）”；
- 用
CallerRunsPolicy：让调用线程自己执行任务。适合低吞吐、可接受延迟上涨的场景，但要注意——如果调用方是 Web 请求线程，可能拖慢整个接口响应 - 包装任务 + 重试 + 落库：对关键任务，提交前先存 DB 或消息队列，再异步提交到线程池；拒绝时触发补偿调度，避免单点失败
- 动态调节参数：通过 Micrometer 暴露
getQueue().size()、getActiveCount()、getCompletedTaskCount()，配合 Prometheus 告警；流量突增时自动扩corePoolSize（需自定义ThreadPoolExecutor子类并重写execute()）
线程池丢任务从来不是玄学问题，而是队列容量、拒绝策略、监控盲区三者叠加的结果。最危险的情况是：用了 DiscardPolicy，又没打日志，还把队列设成无界——你以为任务都排着队，其实它们正默默在内存里膨胀，直到 OOM 或被 GC 清理掉。
