调用 LockSupport.park() 前需做多重条件守卫，即检查中断状态、上下文对象非空及有效状态、许可是否就绪，避免无效等待；park 前须用 isInterrupted() 主动响应中断，校验 task 等关键对象存活性，并同步 unpark 与 park 的协调状态。
调用 LockSupport.park() 前做“多重条件守卫”，核心不是防止“引用断开”（Java 中强引用不会因 park 自动失效），而是防止因中断状态未及时响应、线程已终止、或上下文对象不可达，导致 park 逻辑失去意义或陷入无效等待。所谓“提前断开”，实际指：线程已被中断但未处理、目标对象（如任务、状态容器）已被回收或置 null、park 动机已消失却仍盲目阻塞。
检查中断状态并前置响应
park() 不抛异常，也不自动清除中断标志。若线程在 park 前已被中断，park 会立即返回，造成“看似没阻塞却跳过关键等待”的假象。因此必须在 park 前主动校验：
- 用
Thread.currentThread().isInterrupted()检查当前中断标记（不重置） - 若为 true，应直接退出循环、清理资源、或抛出自定义中断异常（如
InterruptedException包装） - 避免仅依赖 park 返回后才检查——那已错过首次中断时机
守护上下文对象的生命周期
闭包中捕获的对象（如 Runnable、Task、StateHolder）若被 GC 或显式置 null，park 后续唤醒逻辑可能空转或 NPE。需确保：
- 关键对象使用强引用持有，并在 park 前做非空判断（例如：
if (task == null || task.isDone()) return;） - 若对象有明确状态机（如 STARTED / CANCELLED / COMPLETED），在 park 前校验其是否仍处于可等待状态
- 避免在 lambda 中隐式捕获外部局部变量，改用 final 字段或显式传参，增强生命周期可控性
绑定 park 行为与有效唤醒源
park 的语义依赖于后续 unpark 或中断。若 unpark 调用早已发生、或对应线程已 exit，则 park 等同于死等。因此需同步守卫：
- 在 park 前检查是否已有“许可”可用（例如：通过原子布尔标记
readyToProceed.get()） - 若许可已就绪，跳过 park，直接执行后续逻辑
- 将 unpark 和 park 状态统一纳入一个共享协调结构（如 AQS 的 state、或自定义 WaitNode），避免“唤醒丢失”和“重复 park”
组合守卫的典型写法
以下是一个兼顾中断、对象存活、状态就绪的 park 守卫模式：
while (!Thread.currentThread().isInterrupted() && task != null && !task.isCompleted()) {
if (readyFlag.get()) {
break; // 许可已就绪，无需 park
}
LockSupport.park();
}
if (Thread.currentThread().isInterrupted()) {
Thread.currentThread().interrupt(); // 保留中断标记供上层感知
throw new InterruptedException("Task interrupted before park completed");
}
if (task == null || task.isCompleted()) {
return; // 上下文已失效，不继续
}
// 此时可安全执行唤醒后逻辑
