sleep方法会直接触发线程上下文切换，使当前线程进入TIMED_WAITING状态并主动交出CPU，但不释放锁、不改变优先级；休眠到期后线程转为RUNNABLE并进入就绪队列，是否立即执行取决于调度策略。
sleep 方法会直接触发线程上下文切换，但它本身不释放锁，也不改变线程调度优先级，只是让当前线程进入 TIMED_WAITING 状态并主动交出 CPU。
sleep 是一种典型的自发性上下文切换触发点
调用 Thread.sleep() 时，JVM 会向操作系统发出请求，将当前线程挂起指定时间。此时线程状态从 RUNNING 变为 TIMED_WAITING，操作系统立即保存其寄存器、程序计数器、栈指针等上下文，并从就绪队列中选取下一个线程执行——这构成一次完整的上下文切换。
- 即使只休眠 1 毫秒，也可能发生切换（取决于系统调度精度和负载）
- sleep 不依赖同步块或锁，因此在任意代码位置都能引发切换
- 与
wait()不同，sleep 不释放已持有的 monitor 锁
sleep 后线程恢复不等于立刻获得 CPU
休眠时间到期后，线程状态转为 RUNNABLE，但只是进入就绪队列等待调度。是否能马上执行，取决于当前 CPU 负载、线程优先级及调度策略：
- 高并发场景下，可能多个线程同时结束 sleep，竞争 CPU 导致新一轮调度开销
- 若此时有更高优先级线程正在运行，该线程仍需等待
- 频繁调用 sleep（如轮询中使用
sleep(1)）会显著放大上下文切换频率
实际性能影响取决于调用模式和线程数量
单次 sleep 的开销很小，但累积效应明显。尤其在以下情况中，容易成为性能瓶颈：
立即学习“Java免费学习笔记（深入）”；
- 大量线程频繁调用短时 sleep（例如监控线程每 10ms 检查一次状态）
- 线程池中 worker 线程空闲时用 sleep 轮询任务，而非使用阻塞队列的 take()
- 未配合 yield() 或更优机制（如 LockSupport.parkNanos）做精细化控制
替代 sleep 减少切换的常见做法
并非所有等待都需要 sleep；合理选择等待机制可降低无效切换：
- 用
BlockingQueue.take()替代 while + sleep，让线程在无任务时真正阻塞并减少调度压力 - 对定时任务优先使用
ScheduledThreadPoolExecutor，由专用调度线程统一管理，避免每个任务单独 sleep - 高实时性场景考虑
LockSupport.parkNanos()，它语义更底层、开销略低，且可被精确 unpark 唤醒 - 避免在 synchronized 块内调用 sleep，防止锁持有时间人为拉长，加剧其他线程阻塞和切换
