空 while 循环会持续抢占 python 解释器的全局解释器锁（gil），使其他线程（如 psutil 的系统调用）无法及时获得执行机会，从而严重拖慢 i/o 密集型操作；正确做法是使用 threading.event 等同步原语替代忙等待。
空 while 循环会持续抢占 python 解释器的全局解释器锁（gil），使其他线程（如 psutil 的系统调用）无法及时获得执行机会，从而严重拖慢 i/o 密集型操作；正确做法是使用 threading.event 等同步原语替代忙等待。
在 Python 多线程编程中，一个看似无害的“空循环”——例如 while not exit: pass——实则是典型的忙等待（busy waiting）反模式，它不仅浪费 CPU 资源，更会因 GIL（Global Interpreter Lock）调度机制引发严重的线程饥饿问题。
为什么空循环会让 psutil.net_connections() 变慢？
Python 3.11 的 GIL 并非按字节码数量（如旧资料所提的“100 字节码”）切换，而是基于时间片轮转：默认每约 5 毫秒（可通过 sys.setswitchinterval() 调整）尝试释放 GIL，允许其他就绪线程获取执行权。但关键在于：只有当当前线程主动让出（如调用 time.sleep()、I/O 阻塞、或显式释放 GIL 的 C 扩展）时，GIL 才真正被释放。
而纯 Python 空循环（无函数调用、无 sleep、无 I/O）几乎不触发 GIL 释放点，导致该线程长期独占解释器，其他线程（包括主线程中调用 psutil.net_connections() 所依赖的底层 os.readlink 等系统调用）被迫长时间等待，甚至出现数分钟级延迟——这正是你观察到的现象。
从报错堆栈也可印证：KeyboardInterrupt 发生在 os.readlink() 的 lock.acquire() 处，说明主线程正卡在等待系统资源锁，而空循环线程持续霸占 GIL，阻碍了内核态 I/O 的回调与调度。
✅ 正确做法：用 threading.Event 实现高效等待
替代忙等待的标准化方案是使用线程安全的同步原语。threading.Event 是轻量、零开销、且完全符合 Python 并发模型的设计：
import psutil
import threading
import time
# 创建事件对象，初始为未设置状态
stop_event = threading.Event()
def worker_thread(event: threading.Event):
print("Worker thread started, waiting for signal...")
event.wait() # 阻塞直到 event.set() 被调用 —— 不消耗 CPU！
print("Worker thread received signal, exiting.")
# 启动工作线程（设为 daemon=True 可选，避免主程序退出时卡住）
t1 = threading.Thread(target=worker_thread, args=(stop_event,), daemon=True)
t1.start()
# 主线程执行耗时 I/O 操作（如网络连接扫描）
print("Calling psutil.net_connections()...")
start_time = time.time()
connections = psutil.net_connections()
elapsed = time.time() - start_time
print(f"✅ Done in {elapsed:.2f}s. Found {len(connections)} connections.")
# 示例：打印部分端口
for con in connections[:5]:
if hasattr(con.laddr, 'port'):
print(f" Port: {con.laddr.port}")
# 通知工作线程退出
stop_event.set()
t1.join() # 确保子线程结束
? 提示：
event.wait()是可中断的阻塞调用，支持超时（event.wait(timeout=5)）和响应KeyboardInterrupt，远比while not flag: time.sleep(0.01)更优雅可靠。
⚠️ 其他注意事项
-
避免
daemon=False+ 忙等待组合：若子线程未设为 daemon 且含空循环，主程序t1.join()将永远阻塞，无法正常退出。 -
不要手动轮询标志位：即使加了
time.sleep(0.001)，仍属低效方案；Event内部基于操作系统原生事件机制（如 Linux 的 futex），性能与可靠性全面胜出。 -
I/O 密集型任务优先考虑异步：若需高并发网络操作，
asyncio+aiofiles/httpx等异步生态比多线程更合适（规避 GIL 限制）。 -
CPU 密集型任务请用
multiprocessing：GIL 在多进程间不存在，计算任务应交由Process或concurrent.futures.ProcessPoolExecutor。
总结
Python 线程不是“并行执行”的银弹——GIL 是其设计基石，理解它如何与 I/O、sleep、C 扩展交互，是写出高性能并发代码的前提。永远用 threading.Event、threading.Condition 或 queue.Queue 替代空 while 循环；这不仅是最佳实践，更是对解释器调度机制的基本尊重。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
