五个执行语境概念辨析：请求/会话/进程/线程/事务

谈并发离不开先厘清几个执行语境概念，它们粒度依次增大、互相嵌套。请求：外部环境发出的单个调用，处理过程主要在服务器端进行，客户端等待应答；同一用户连续发出的两个请求（如先下单再取消）在服务器看来是否有关联，取决于所用协议是否记录了这层关系。会话：客户端与服务器之间一次较长时间的交互，通常由一连串用户认为逻辑上相关的请求构成，一般始于登录、终于用户退出（或被系统判定为离开）；服务器软件往往同时活跃着两种会话——面对客户端的HTTP会话，以及作为其他系统客户端时发起的数据库会话。进程：操作系统级别的重量级执行语境，把内部数据与外界隔离开；线程：进程内部的轻量级活跃执行单元，一个进程可以容纳多个线程，人们爱用线程是因为能在单进程内同时服务多个请求、充分利用资源，但线程通常共享内存，这正是并发问题的源头（也存在不共享内存的”孤立线程”设计）。事务：处理数据库时的另一个重要语境，能把多个请求当作单个请求对待，可能发生在应用程序与数据库之间（系统事务），也可能发生在用户与应用程序之间（业务事务）——这组区分对理解后续的离线并发问题至关重要。理论上每个会话独占一个进程能最大限度减少并发冲突，但现实中很少有服务器工具支持这么做；早期Perl Web系统曾”每请求一进程”，如今因创建进程开销大而少用，”一个进程一次只处理一个请求”仍是常见的规避并发的简单做法。

结构图：

flowchart TB
  A["执行语境粒度"]
  A --> B["请求:单次调用<br/>关联性依赖协议"]
  A --> C["会话:一连串相关请求<br/>登录到退出"]
  A --> D["进程:重量级隔离单元"]
  A --> E["线程:进程内轻量级单元<br/>共享内存是并发问题源头"]
  A --> F["事务:把多请求当单请求<br/>系统事务(应用↔数据库) vs 业务事务(用户↔应用)"]