Python selectors.DefaultSelector 怎么收口多路 IO：注册、事件掩码与关闭顺序

用 Python 写一个同时照看多条非阻塞 socket 的小服务时，最容易失控的不是监听，而是收尾：事件循环拿到的到底是哪一个连接，连接关闭后是否还留在 selector 里，selector 自己又有没有释放底层资源。selectors.DefaultSelector 的实用边界可以压缩成一句话：先用 register 声明关注的事件，再用 select 取出已就绪对象，连接关闭时先 unregister，最后关闭 selector。

把“监听对象”“就绪事件”和“连接生命周期”分开管理，才能让多路 IO 的循环既不误读，也不会把已关闭的文件描述符留在监控集合里。

DefaultSelector 解决的是哪一层问题

selectors 是 Python 对底层 select 原语的高层封装。DefaultSelector 不是一个固定的内核实现，而是当前平台可用实现中的默认选择。代码只依赖统一的注册、等待和移除接口，Linux、macOS 或其他支持的平台可以由运行环境决定具体实现。

它等待的是“文件对象是否就绪”，这里的文件对象可以是带有 fileno() 的对象，也可以是文件描述符。Windows 对可监控对象的限制与 Unix 不同，不能把“能注册”误解成“所有文件都能按同样方式等待”。

注册阶段：把 socket 和处理动作绑在一起

下面的最小示例只处理读事件。监听 socket 的 data 放入 accept_connection，客户端 socket 的 data 放入 read_connection。这样事件循环只需从 key.data 取出动作，不用按文件描述符再查一次字典。

import selectors
import socket

selector = selectors.DefaultSelector()

def accept_connection(server, mask):
    connection, address = server.accept()
    connection.setblocking(False)
    selector.register(connection, selectors.EVENT_READ, read_connection)

def read_connection(connection, mask):
    data = connection.recv(4096)
    if data:
        connection.sendall(data)
    else:
        selector.unregister(connection)
        connection.close()

server = socket.socket()
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
server.bind(("127.0.0.1", 9000))
server.listen()
server.setblocking(False)
selector.register(server, selectors.EVENT_READ, accept_connection)

这里有两个细节值得保留。第一，注册前把 socket 设为非阻塞，否则回调里的单次 accept() 或 recv() 仍可能把整个循环卡住。第二，同一个 file object 重复 register() 会触发 KeyError，需要修改事件时使用 modify()，不要偷偷再注册一次。

select 返回什么：先看事件，再决定动作

事件循环通常写成下面这样。select() 返回一组 (key, events)，其中 key.fileobj 是已注册对象，key.data 是注册时附着的数据，events 是这一次真正就绪的位掩码。

while True:
    ready = selector.select(timeout=1)
    for key, events in ready:
        callback = key.data
        callback(key.fileobj, events)

timeout 大于零时表示最长等待秒数；小于等于零时不阻塞；传入 None 则一直等待。收到信号时也可能提前得到空列表，所以空结果不一定代表 selector 出错，循环应把它当成一次没有可处理事件的机会。

如果同时关注读写事件，回调必须继续检查位掩码，而不是看到 key 就无条件执行写操作：

def dispatch(key, events):
    if events & selectors.EVENT_READ:
        read_connection(key.fileobj, events)
    if events & selectors.EVENT_WRITE:
        flush_pending_data(key.fileobj)

关闭顺序：unregister 要早于 socket.close

读回空字节通常意味着对端已经有序关闭连接。此时要先执行 selector.unregister(connection)，再执行 connection.close()。官方文档明确要求文件对象关闭前先从 selection 中移除，否则事件集合仍可能保留一个已经失效的对象。

服务整体退出时，还要处理监听 socket 和 selector 本身。一个可复用的收尾函数如下：

def close_connection(connection):
    try:
        selector.unregister(connection)
    except KeyError:
        pass
    finally:
        connection.close()

def shutdown(server):
    close_connection(server)
    selector.close()

这里捕获 KeyError 只适合“收尾动作可能被重复调用”的场景，例如异常分支已经移除了连接。不要用它掩盖正常流程中的重复注册或对象错配。selector.close() 之后不要再次调用 select()、register() 或 get_map()。

三个容易误判的边界

可读不等于一定有业务数据

socket 可读可能是有数据，也可能是对端关闭或发生错误。recv() 得到空字节时应进入关闭路径，而不是继续注册读事件。

EVENT_WRITE 不应永久打开

大多数 socket 在没有待发送数据时都可写。如果一直注册 EVENT_WRITE，循环可能反复被唤醒。只有发送缓冲区确实有数据时才关注写事件，发送完成后用 modify() 退回只监听读事件。

select 的结果不是永久承诺

返回的就绪状态只对应这一轮等待。回调执行前后对象状态可能改变，因此每次都应重新检查缓冲区和连接状态，不能缓存一份 ready 列表跨轮使用。

相关问题

DefaultSelector 和直接使用 epoll 有什么区别？

DefaultSelector 提供跨平台的高层接口，通常足够组织应用层事件循环；只有确实需要某个内核实现的专属能力时，才考虑直接使用 epoll 等底层接口。

可以直接关闭已注册的 socket 吗？

不建议。先 unregister，再 close，最后在整体退出时关闭 selector，生命周期更清楚，也符合官方接口契约。

为什么 select(timeout=1) 返回空列表？

可能是超时，也可能是信号导致提前返回。空列表只说明这次没有可直接处理的就绪对象，不代表所有连接都已断开。

收口检查清单

• 所有注册对象都已设为非阻塞，并且每个对象只注册一次。
• 回调从 key.data 取得，按 events 位掩码选择读或写动作。
• 连接关闭路径先 unregister 再 close，重复收尾时能识别已移除对象。
• 服务退出路径关闭监听 socket 后再关闭 selector，且不再使用已关闭的 selector。