Python http.server 共享状态时如何避免线程请求互相覆盖

你在用Python内置的http.server开发简单Web服务时，如果有跨请求共享状态的需求，直接操作全局可变变量很容易碰到多线程并发冲突，不同请求的数据互相覆盖的问题，只要给共享资源加线程互斥锁做访问限制，或者把单请求独立的属性绑定到当前处理线程的上下文里，就能避免这类异常。

所有多线程都会读写的共享可变状态，必须加互斥锁做同步保护，仅当前请求用到的私有数据不要存到全局域，直接挂到当前请求处理实例的属性下，就能彻底杜绝不同请求线程互相覆盖数据的问题。

用 ThreadingHTTPServer 做本地接口时，最容易忽略的不是端口，而是 handler 线程之间共享了同一个可变对象。两个请求都先读到旧计数，再分别写回新值，就会出现请求明明处理了 100 次，结果却只有 63 次的情况。解决办法是：把共享状态放到 server 对象上，用 threading.Lock 保护最小的读改写区；响应发送、文件读取和其他慢操作放在锁外。

先把共享状态的边界画出来

BaseHTTPRequestHandler 实例适合保存当前请求的数据；如果计数要跨请求保留，就应放在自定义 server 实例上。这样做的关键不是“所有代码都加锁”，而是明确谁拥有状态、哪段代码会同时读写。

from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
import json
import threading

class AppServer(ThreadingHTTPServer):
    # server 对象保存跨请求状态；锁与状态必须属于同一个生命周期
    def __init__(self, address, handler):
        super().__init__(address, handler)
        self.state = {"count": 0, "recent": []}
        self.state_lock = threading.Lock()

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        # 一次完整的读改写必须在同一把锁内完成，避免丢失更新
        with self.server.state_lock:
            self.server.state["count"] += 1
            self.server.state["recent"] = (self.server.state["recent"] + [self.path])[-10:]
            snapshot = {
                "count": self.server.state["count"],
                "recent": list(self.server.state["recent"]),
            }

        # 锁外只使用快照，避免网络写入拖住其他请求
        body = json.dumps(snapshot, ensure_ascii=False).encode("utf-8")
        self.send_response(200)
        self.send_header("Content-Type", "application/json; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)

这里的锁覆盖了“读取旧值、修改、生成快照”三个动作。只锁住 += 1 仍然可能让最近请求列表和计数来自不同时间点；反过来，把 wfile.write() 放进锁里又会让慢客户端阻塞所有请求。

基线指标要能复现，而不是凭感觉判断

可以把初始计数清零，连续发固定数量的并发请求，再比较最终值和预期值。下面的客户端只负责制造压力，文章中的数值是说明并发覆盖问题的示例，不代表某台机器的固定性能。

from concurrent.futures import ThreadPoolExecutor
from urllib.request import urlopen

def hit(_):
    # 每个任务访问同一个接口，响应内容只用于确认请求完成
    with urlopen("http://127.0.0.1:8000/hit", timeout=2) as response:
        return response.status

with ThreadPoolExecutor(max_workers=16) as pool:
    statuses = list(pool.map(hit, range(100)))

# 只统计完成的请求，最终 count 应与成功请求数一致
print(sum(status == 200 for status in statuses))

锁不是所有共享数据的终点

这套方案只适合单进程内的短小状态。若请求要排队处理，用 queue.Queue 比让多个线程抢同一个列表更直观；若数据要在多个进程或多台机器间共享，应使用数据库、Redis 等外部存储。ThreadingHTTPServer 也更适合开发工具和小型内部服务，正式生产服务要额外考虑超时、连接关闭、日志和进程模型。

还有一个常见坑：不要把锁定义在 do_GET() 内部，那样每次请求都会得到新锁，线程之间根本无法互斥。锁必须与共享状态拥有相同的生命周期。

相关问题

为什么有了 GIL 还会丢计数？

GIL 不等于业务级读改写原子性。线程可能在读取旧值后切换，另一个线程完成同样的读取，最后两个结果互相覆盖。

可以用 RLock 替代 Lock 吗？

可以，但只有同一线程需要嵌套获取同一把锁时才有必要。普通的共享计数优先使用 Lock，边界更简单。

为什么要复制 recent 列表？

复制后响应使用的是稳定快照，锁释放后其他线程继续更新原列表，也不会改变当前响应准备发送的数据。