队列只有十个请求也会占很多内存，怎样同时限制请求数和字节数

队列只有十个请求，仍可能占用很多内存，因为请求体大小并不相同。本文用九个五字节小请求和一个八十字节大请求，比较只限条数与条数加字节双限额，并检查取消后的预算回收。统计对象是保留请求体载荷，不是进程总内存。

在入队前同时检查两个维度

合成条数上限十，字节上限一百。只限条数时十项全部进入，共一百二十五字节；双限额先收九项小请求，占四十五字节，大请求进入会超过一百，因此拒绝，接受数九。拒绝项不能先加计数再忘记减，也不应在其他后台列表里保留同样的完整请求体。

字节应按最终保留形式核对。UTF-8文本、解码后的字符串、压缩输入与解析对象的大小不是同一个数。附件为了能手算，直接给载荷字节估算，未测Python对象元数据、复制次数或RSS。实际预算还需为运行中请求、连接池和日志等独立占用留余量，不能因为载荷没超过一百就承诺绝不会OOM。

取消和出队必须释放同一份占用

取消小请求s0后，队列剩八项，字节从四十五降到四十。参考器断言当前字节等于仍在队列里的项大小总和，且不为负数。重复取消不应再减五，已经出队进入执行态的请求也不能同时从队列和执行预算里重复释放。每项最好有明确所有者和状态迁移。

当一个请求体本身大于字节上限时，不能把它放进“等到队列空就能进入”的等待路径，因为永远不可能满足。应在入队前明确拒绝或改走另一条受控处理方式，并给调用方稳定原因。长时间排队还需独立截止，不能因为条数与字节有空余就无限保留过期请求。

用守恒记录审查资源路径

Python有界队列的maxsize按条数限制，字节维度需要额外实现；Docker内存限制也不能自动替你管理应用内请求体生命周期。可在每个入队、出队、取消、拒绝后记录载荷计数与字节，总和应能从当前集合重算，异常退出后也要检查是否留有孤儿占用。

本实验仅顺序回放内存字典，没有测线程竞争或真实HTTP上传。并发实现需要把双条件检查与占位放在一个原子步骤，否则两个请求可能同时看见剩余空间再一起超额。交付的九项接受、四十五字节高位和取消后四十字节，是该参考契约的答案。接到网关之前先把每条释放路径跑对，可以避免只观察队列长度而漏掉载荷膨胀与取消泄漏。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C035。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文只强调队列长度和等待时限；本文以请求体大小不同的作业集验收双维准入与取消回收，区别于C016流式响应缓冲。