守护线程做日志刷盘需在start前设为daemon，接受强制中断，避免资源泄漏；用双缓冲+原子切换提升吞吐，缓冲区控制在毫秒级积压量以最小化丢失。
直接用守护线程做日志刷盘，核心是让日志写入彻底脱离主业务生命周期——主流程结束，JVM 退出，日志线程自动收尾，不卡、不报错、不丢关键数据（容忍少量缓冲区未落盘）。这不是“加个线程就完事”，而是要匹配守护线程的天然行为边界。
守护线程必须在启动前设为 daemon
这是硬性前提，错过时机就会抛 IllegalThreadStateException：
- 创建线程对象后、调用 start() 前，立刻执行 setDaemon(true)
- 不要依赖子线程继承父线程属性——主线程默认非守护，子线程也默认非守护，必须显式设置
- 不能在 run() 方法里尝试切换，也没有 getDaemon() 反查必要；角色从 new 出来那一刻就固定了
刷盘逻辑必须接受“强制中断”现实
守护线程被 JVM 杀掉时，不会执行 finally、不触发 shutdown hook、不走异常处理器。所以设计上要放弃“可靠收尾”幻想：
- 避免在守护线程中打开文件句柄、数据库连接或 socket——这些资源没有释放机会
- 缓冲区刷盘用 writev 或单次 write 批量输出，而不是逐行 fwrite；已刷出的数据是安全的，未刷的缓冲区内容可丢弃
- 若需最小化丢失，可将缓冲区大小控制在毫秒级积压量（如 1MB 或 10ms 日志量），而非追求全量持久化
主业务退出前无需 join，但需确保线程已启动
守护线程不参与 JVM 退出等待，所以你不该也不必调用 join()。但要注意两个常见陷阱：
- 线程对象创建后忘了 start()，导致日志完全不工作——检查日志组件初始化路径是否真触发了线程启动
- C++ 场景下 std::thread 析构前未 join/detach 会直接 terminate 进程；Java 中无此问题，但习惯上仍建议封装成懒加载+自动启动模式
- 可在日志类构造时启动线程，并用 atomic
标记状态，避免重复 start
配合双缓冲与原子切换提升吞吐
前端业务线程只做内存追加，后台守护线程专注刷盘。用双缓冲 + 原子索引规避锁竞争：
- 定义 std::atomic
current_buffer{0} （C++）或用 volatile + synchronized 包裹索引（Java） - 写线程 append 到 buffer[current_buffer.load()]，满则通知刷盘线程
- 刷盘线程用 exchange 原子翻转索引，拿到旧缓冲区地址后 flush，再清空该缓冲区
- 不依赖 ++ 或 ! 操作原子变量——它们不是原子读-改-写，容易出竞态
