为什么线程不是一个好主意

原文在这里：
Why Threads are a bad idea
这是发的第一篇翻译文章，以前只看，没翻译过，大家多多谅解

为什么线程不是一个好主意

简介

一. 关于线程

1.从进程中产生
2.被当作用户层工具
3.认为可以解决各种各样的问题
4.真的每个程序员都应该懂线程吗?

二.存在的问题

非常难以编程

三.替代品

事件

四.声明

1.对于大部分线程适用的环境，事件通常更好
2.线程应该只用在真正的CPU并发环境

什么是线程

• 并发的通用解决方案
• 多个独立的逻辑执行流
• 共享状态
• 抢先调度
• 同步(比如锁等)

  线程的作用

• 操作系统：一个进程只能有一个核心线程
• 科学应用：一个线程一个CPU(处理起来更快)
• 分布式系统：并发处理请求
• 图形界面：一个线程处理用户行为，在进行长时间运算时不至于失去响应 ;多媒体，动画等方面

  线程错在哪

• 对于大多数程序员太难使用
• 即使是专家，用起来也很痛苦
  

  为什么线程很难

  同步

  必须用锁来协调对数据的访问，一旦忘记，等待你的就是被毁坏的数据

  死锁

  锁的循环依赖；每个进程会出现等待的情况，导致系统挂起
  

  难以调试

  数据的相互依赖，时间上的依赖

  线程破坏了抽象

  无法独立地设计模块

  在有锁的情况下无法回调

  

  难以高效：

• 过于简单的锁导致低并发
• 细粒度的锁增加了复杂度，而且在通常情况下并不高效
• 系统限制了性能(比如调度和上下文切换等开销)

线程没有得到很好的支持

• 难以移植线程相关代码(比如PC和Mac)
• 标准库通常都不是线程安全的
• 内核调用，窗口系统通常都不是多线程的
• 很少调试工具(仅有LockLint和调试器？)

你通常不需要并发(比如窗口事件)

事件驱动编程

• 一个执行流，没有CPU并发
• 根据兴趣注册事件(回调)
• 循环等待事件，调用事件处理程序
• 不会有抢占调度情况
• 事件处理程序通常生命周期很短
  

  事件驱动的使用场景

  (to be continued)