图片分发必须由用户线程承载，禁用守护线程处理关键i/o；需显式同步等待写入完成、强制刷盘、校验哈希并支持重试与异步完整性检查。
图片动态分发逻辑中若依赖守护线程写入文件，极易因 JVM 强制终止导致尾部字节丢失或截断——这不是线程“没写完”，而是 JVM 在所有用户线程退出瞬间直接杀掉守护线程，连 finally 块、try-with-resources 自动关闭、甚至 FileChannel.force(true) 都来不及执行。
守护线程不能用于关键 I/O 任务
守护线程的定位是后台支撑型任务（如 GC 日志轮转、JMX 监控上报），不是业务级资源操作载体。图片分发属于核心交付行为，必须由用户线程承载生命周期：
- 所有涉及文件写入、网络响应、磁盘刷盘的线程，一律设为非守护线程（默认即如此）
- 避免在守护线程内启动子线程去处理图片——子线程默认继承 daemon 属性，仍不可靠
- 不要用守护线程做“临时缓冲写入”，哪怕只差最后 1KB，损坏就是 100% 不可用
用显式同步机制确保写入完成再退出
主线程或业务线程不能“假定”图片已发完就直接结束。需主动等待关键 I/O 线程安全终止：
- 使用
CountDownLatch或CyclicBarrier：分发线程完成写入并调用latch.countDown()后，主流程再await() - 对
ExecutorService调用shutdown() + awaitTermination(timeout, unit)，超时后检查isTerminated() - 写入完成后强制刷盘：
fileOutputStream.getChannel().force(true)，再确认fileOutputStream.close()返回
加校验与兜底恢复能力
即使流程正常，磁盘缓存、OS 调度异常也可能造成尾部损坏。应在交付链路中嵌入防护：
- 生成图片时同步计算并存储校验值（如 CRC32 或 xxHash），响应头中带上
Content-MD5或自定义校验字段 - 客户端收到响应后校验长度与哈希值，失败则触发重试或降级（如返回占位图 + 上报告警）
- 服务端可配置异步校验任务，在写入后几秒内读取文件末尾 1–2KB 检查结构完整性（如 PNG 的 IEND 块、JPEG 的
FF D9）
慎用 shutdown hook 替代守护线程
有人试图把写入逻辑挪进 JVM 关闭钩子（Runtime.getRuntime().addShutdownHook()）来“补救”。这不可靠：
- shutdown hook 本身也是被强制中断的——它不比守护线程更“优雅”
- 多个 hook 执行顺序不确定，无法保证依赖关系
- 若主流程已因 OOM 或 kill -9 终止，hook 根本不会触发
- 正确做法是：让业务线程自己管理退出时机，而不是寄希望于 JVM 最后的“临终托付”
