并发

副标题 / 摘要 线程可以理解成“多人同时做饭”。本文用厨房类比解释线程与并发的核心概念。 目标读者 需要做技术科普的开发者 初学并发概念的读者 想提升沟通表达能力的人 背景 / 动机 线程是并发编程的基础，但概念抽象。 用日常类比能更容易让非技术人员理解。 核心概念 线程：程序里“同时做事”的小工人 共享资源：厨房、炉灶、锅 冲突：两个人争同一口锅 实践指南 / 步骤 用厨房类比：多个人一起做饭 说明共享资源：同一口锅会抢 引入协调：排队或分配任务 强调目标：更快完成大餐 可运行示例 import threading def cook(name): print(name, "is cooking") if __name__ == "__main__": t1 = threading.Thread(target=cook, args=("Alice",)) t2 = threading.Thread(target=cook, args=("Bob",)) t1.start() t2.start() t1.join() t2.join() 解释与原理 线程就像厨房里的多位厨师，能够同时做不同的菜。 但如果大家都抢同一个锅，就会产生冲突，需要协调。 常见问题与注意事项 线程越多越快吗？ 不一定，冲突和切换会带来开销。 线程和进程一样吗？ 线程共享资源更多，进程更独立。 为什么会出错？ 因为共享资源需要同步保护。 最佳实践与建议 用生活类比解释抽象概念 强调“共享资源”的风险 引入锁或队列的概念 小结 / 结论 线程就是“多个厨师同时做饭”。 理解共享资源与协调机制是并发入门的关键。 ...

副标题 / 摘要 Wait-free 表示“每个线程都能在有限步内完成操作”。本文对比 wait-free 与 lock-free，并解释适用场景。 目标读者 关注并发正确性与性能的工程师 学习无锁算法的开发者 需要理解进度保证的架构师 背景 / 动机 在高并发系统里，阻塞可能导致长尾延迟。 Wait-free 提供最强的进度保证，但实现成本也最高。 核心概念 Wait-free：每个线程都有完成上界 Lock-free：整体有进展，但可能单线程饥饿 Obstruction-free：无干扰时可完成 实践指南 / 步骤 先评估是否需要最强保证 优先使用成熟的无锁数据结构 对关键路径进行延迟测量 用限制争用的设计降低复杂度 可运行示例 # “每线程独立槽位”示例：写入无需等待其他线程 from concurrent.futures import ThreadPoolExecutor def write_slot(slots, idx, value): slots[idx] = value if __name__ == "__main__": slots = [None] * 4 with ThreadPoolExecutor(max_workers=4) as ex: for i in range(4): ex.submit(write_slot, slots, i, i * 10) print(slots) 解释与原理 Wait-free 的关键是“每个线程都不依赖别人完成”。 上例中每个线程写自己的槽位，不会等待锁或其他线程。 常见问题与注意事项 Wait-free 就一定更快吗？ 不一定，实现复杂度和常数成本更高。 ...

副标题 / 摘要 线程饿死并不是死锁，但同样会让系统“挂住”。本文解释饿死的原因与工程解决办法。 目标读者 处理高并发系统的后端工程师 需要理解调度与锁的开发者 负责性能与稳定性的技术负责人 背景 / 动机 在多线程系统中，即使没有死锁，某些线程也可能长期得不到资源。 这会造成延迟暴涨、任务超时与系统不公平。 核心概念 饿死（Starvation）：线程长期无法获得所需资源 不公平锁：没有公平队列的锁 优先级反转：低优先级阻塞高优先级 实践指南 / 步骤 优先使用公平锁或限时锁 避免长时间占有锁 在关键路径引入超时与降级 监控等待队列长度与等待时间 可运行示例 # 简化“饿死”示意：高优先级任务不断插队 def scheduler(high_tasks, low_tasks, steps=6): done = [] for _ in range(steps): if high_tasks: done.append(high_tasks.pop(0)) # 高优任务持续补充 high_tasks.append("H") elif low_tasks: done.append(low_tasks.pop(0)) return done if __name__ == "__main__": print(scheduler(["H", "H"], ["L1", "L2", "L3"])) 解释与原理 当调度策略持续优先处理高优任务时，低优任务可能永远排不到。 这不是死锁，而是不公平调度导致的饥饿现象。 常见问题与注意事项 饿死一定是 bug 吗？ 可能是设计问题，比如不公平调度策略。 公平锁就一定没问题吗？ 不一定，公平锁可能降低吞吐。 如何定位饿死问题？ 观察锁等待时间、队列长度与任务超时。 ...

副标题 / 摘要 竞态条件是并发中最隐蔽的 bug 类型之一，源于对共享状态的非原子操作。本文给出可运行示例与规避方法。 目标读者 需要理解线程安全的工程师 做并发开发与性能优化的开发者 负责可靠性与稳定性的技术负责人 背景 / 动机 竞态条件会导致偶发错误：你很难复现，但它确实存在。 理解其成因，才能正确使用锁、原子操作与无锁结构。 核心概念 共享状态：多线程同时访问的变量 非原子操作：读-改-写不是一个不可分割的步骤 临界区：必须串行访问的代码区域 实践指南 / 步骤 识别共享状态 确定临界区 使用锁或原子操作保护 最小化临界区范围 用竞态检测工具验证 可运行示例 import threading counter = 0 def inc(): global counter for _ in range(100000): counter += 1 if __name__ == "__main__": t1 = threading.Thread(target=inc) t2 = threading.Thread(target=inc) t1.start() t2.start() t1.join() t2.join() print(counter) 在部分解释器/实现中可能输出小于 200000，这就是竞态。 解释与原理 counter += 1 并不是原子操作，它包含读取、加一、写回三个步骤。 两个线程交错执行时会丢失更新。 ...

副标题 / 摘要 死锁发生在多个线程互相等待对方持有的资源。本文解释成因、给出示例，并总结规避方法。 目标读者 需要理解并发风险的工程师 负责系统可靠性的开发者 做并发设计评审的技术负责人 背景 / 动机 死锁通常在压力或线上才出现，一旦发生会导致服务完全卡住。 理解死锁条件并提前规避，是并发系统的必修课。 核心概念 互斥：资源一次只能被一个线程占用 占有且等待：拿着资源还要等另一个资源 不可抢占：资源不能被强制夺取 循环等待：形成等待环 实践指南 / 步骤 统一锁顺序（按固定顺序获取） 减少锁数量 设置超时与回退 用锁分层减少交叉等待 监控阻塞与持锁时间 可运行示例 import threading import time lock_a = threading.Lock() lock_b = threading.Lock() def t1(): with lock_a: time.sleep(0.1) with lock_b: pass def t2(): with lock_b: time.sleep(0.1) with lock_a: pass if __name__ == "__main__": threading.Thread(target=t1).start() threading.Thread(target=t2).start() time.sleep(1) print("可能已死锁") 解释与原理 当 t1 拿着 A 等 B，而 t2 拿着 B 等 A，就形成循环等待。 满足四个必要条件时死锁发生。 ...

副标题 / 摘要 并发测试困难的根源在于非确定性与时序组合爆炸。本文解释为什么难、难在哪里，并给出工程实践建议。 目标读者 做并发/多线程开发的工程师 负责可靠性与测试的团队 想理解“偶发 bug”为何难测的人 背景 / 动机 并发 bug 往往“偶发、难复现、线上才出现”。 这是因为并发调度不可预测，导致测试难以覆盖所有时序组合。 核心概念 非确定性：调度顺序不可预测 时序组合爆炸：线程交错排列数量巨大 Heisenbug：调试本身改变时序 可复现性：复现条件苛刻 实践指南 / 步骤 把并发边界缩小（减少共享状态） 引入确定性调度或模拟器 使用竞态检测工具（如 TSAN） 加大压力与重复运行（概率提高） 记录关键事件与时间线 可运行示例 下面例子展示“偶发错误”很难稳定复现： import threading x = 0 def worker(): global x for _ in range(100000): x += 1 if __name__ == "__main__": threads = [threading.Thread(target=worker) for _ in range(2)] for t in threads: t.start() for t in threads: t.join() print(x) 在某些语言/环境下会出现不一致结果，这就是并发非确定性。 解释与原理 并发执行时，读-改-写不是原子操作。 调度顺序变化会导致结果不同，而这类问题很难通过少量测试覆盖。 ...

副标题 / 摘要 并发不是为了“更快”，而是为了更好地利用等待时间。本文解释并发的价值，并给出工程实践的判断与示例。 目标读者 希望提升系统吞吐的后端工程师 经常处理 I/O 等待的开发者 需要做性能与架构决策的技术负责人 背景 / 动机 很多程序在等待 I/O（磁盘、网络、数据库）时并不占用 CPU。 并发让 CPU 在等待期间去做别的事，从而提高吞吐、降低整体延迟。 核心概念 吞吐（Throughput）：单位时间内处理的请求数量 延迟（Latency）：单个请求完成的时间 I/O 等待：CPU 空闲但任务阻塞 并行与并发：并行是同时执行，并发是交错执行 实践指南 / 步骤 判断瓶颈是否来自 I/O 优先使用异步或多线程处理 I/O 对 CPU 计算使用并行 限制并发度，避免过度上下文切换 监控吞吐与尾延迟 可运行示例 下面对比串行与并发请求： import time import threading def io_task(i): time.sleep(0.2) return i def serial(n): start = time.time() for i in range(n): io_task(i) return time.time() - start def concurrent(n): start = time.time() threads = [] for i in range(n): t = threading.Thread(target=io_task, args=(i,)) t.start() threads.append(t) for t in threads: t.join() return time.time() - start if __name__ == "__main__": print("serial:", serial(5)) print("concurrent:", concurrent(5)) 解释与原理 串行执行时，5 个 I/O 等待累加。 并发执行时，等待时间重叠，整体耗时接近单个 I/O 的时间。 ...