DiscardPolicy适用于日志采集、埋点上报、监控推送等允许丢失的非关键任务，但存在静默丢弃、掩盖过载、不可重试等隐患，使用前需确认业务影响、兜底机制及监控告警。
DiscardPolicy 适合丢得起、不care结果的任务，比如日志采集、埋点上报、监控指标推送这类非关键操作。它不做任何处理，连日志都不打，就让任务“凭空消失”。
典型适用场景
这些地方用 DiscardPolicy 合理且常见：
- 异步日志写入：应用把日志丢进线程池后不等结果，丢了也不影响主流程，后续有本地文件缓冲或批量重传机制兜底
- 用户行为埋点：页面点击、曝光事件量大且允许少量丢失，强一致性不是刚需
- 健康检查上报：向注册中心发心跳或指标，偶尔漏一次不影响服务发现逻辑
- 低优先级通知：比如非紧急的内部告警摘要，晚发或不发都可接受
关键隐患必须警惕
表面省事，但容易埋雷：
- 完全静默，无任何反馈：任务被丢弃时既不抛异常，也不打日志，问题发生时难以察觉，排查成本高
- 掩盖容量瓶颈：系统持续丢任务却不报警，可能让人误判线程池配置合理，实则已长期过载
- 丢失不可逆：不像 CallerRunsPolicy 或 DiscardOldestPolicy 还有补救路径，DiscardPolicy 是彻底放弃，无法重试或降级
- 与业务语义冲突：若看似“非关键”的任务实际承载了状态变更（如某类缓存清理），丢弃可能导致数据不一致
使用前建议确认三点
别只看文档说“丢就丢了”，上线前理清：
立即学习“Java免费学习笔记（深入）”；
- 这个任务丢失后，是否真不影响用户功能、资损、对账或监控准确性？
- 是否有其他机制（如本地队列、落盘暂存、上游重推）能覆盖丢弃缺口？
- 是否已在监控中对
RejectedExecutionException或线程池拒绝数做了告警？DiscardPolicy 虽不抛异常，但可通过ThreadPoolExecutor.getRejectedExecutionHandler()配合自定义包装器埋点统计
