LockSupport 的线程挂起与唤醒依赖线程私有的 permit 状态（0 或 1），unpark 设为 1 可预发，park 检查并消耗；permit 由 JVM 在 native 层维护，非 public 变量，原子且天然可见，但不保证共享变量同步。
LockSupport 的线程挂起与唤醒，底层不依赖任何用户可见的“变量”，而是靠每个线程内部隐式关联的一个 许可（permit）状态。这个 permit 是一个二值信号量：取值只能是 0 或 1，不可累加，也不可负值。
permit 是怎么工作的
每个 Java 线程在创建时，JVM 就为其初始化了一个 permit，初始值为 0。
- unpark(Thread t)：将目标线程 t 的 permit 设为 1。如果 t 此时正 park 着，就立刻唤醒；如果 t 还没 park，这个 1 就“存着”，等下一次 park 时直接消耗并返回。
- park()：检查当前线程的 permit。如果是 1，就清零并立即返回（不挂起）；如果是 0，才真正调用底层 unsafe.park() 进入阻塞状态。
- 连续两次 unpark(t) 和只调用一次效果完全一样——permit 不会变成 2，它始终最多为 1。
为什么没有显式变量，却能跨线程生效
permit 并非存在某个 public 字段或静态变量里，而是由 JVM 在线程对象（java.lang.Thread 实例）的 native 层面维护的一块私有状态。LockSupport 只是通过 Unsafe 提供的接口去读写它。
- 这种设计避免了锁竞争和内存可见性问题——permit 修改本身是原子的，且对调用 park 的线程天然可见。
- 但注意：unpark() 不保证其前置的共享变量修改对被唤醒线程可见。例如你改了 volatile boolean ready = true，再 unpark(t)，t 唤醒后仍需重新读 ready，不能假设 ready 已同步。
- 若需确保状态可见，应在 unpark 前用 volatile 写、或加内存屏障（如 VarHandle.fullFence）。
常见误解：permit 是不是像 CountDownLatch 那样的计数器
不是。CountDownLatch 的 count 是可减、可等待、可重置的整型变量；permit 是线程私有的、仅用于控制 park 行为的单比特开关。
- 它不参与条件判断逻辑，不暴露给业务代码，也不能被用户直接读取或修改。
- 它的存在只为解决 wait/notify 最头疼的问题：信号丢失。因为 permit 可“预发”，所以 unpark 先于 park 完全合法且安全。
- 调试时看不到 permit 值，只能通过 Thread.getState() 辅助判断：WAITING/TIMED_WAITING 说明真挂起了；RUNNABLE 则可能 permit 已就绪。
底层真正干活的是 Unsafe.park()
LockSupport 所有 park/unpark 的实际阻塞与唤醒动作，都委托给了 sun.misc.Unsafe 类的 native 方法：
- Unsafe.park(boolean isAbsolute, long time)：最终调用操作系统级的线程挂起原语（如 Linux 的 futex_wait 或 pthread_cond_wait）。
- Unsafe.unpark(Thread t)：触发对应线程的唤醒事件，通知内核调度器恢复该线程运行。
- 这些操作绕过了 Java 对象监视器（monitor），因此无需 synchronized，也没有锁升级、偏向锁等开销。
