semaphore用于控制对象池中同时被借出的对象数量上限，而非锁定对象本身；它通过许可（permit）机制管理并发使用数，acquire获取许可后借用对象，release归还许可并重置对象状态，确保最大并发数严格受限且不泄漏许可。
在富文本编辑器的后端逻辑中，对象池（Object Pool）用于复用频繁创建/销毁的解析组件（如 HTML 节点处理器、AST 转换器、样式计算单元等），以降低 GC 压力和提升吞吐。而 Semaphore 并不用于“锁死对象”本身，而是控制**同时被借出（in-use）的对象数量上限**——这是资源隔离与稳定性保障的关键一环。
明确 Semaphore 的作用边界
Semaphore 是一个计数信号量，它不绑定具体对象实例，也不感知对象生命周期；它只管控「许可（permit）」的发放与归还。在对象池中，它的职责是：
- 借出对象前，尝试 acquire 一个 permit；失败则阻塞或快速失败（取决于构造参数）
- 归还对象时，必须调用 release 归还 permit，否则池将“漏许可”，导致后续无法借出
- permit 总数 = 池中**最大可并发使用对象数**，而非对象总数（闲置对象不占 permit）
对象池 + Semaphore 的协同设计要点
需将 permit 获取与对象借用解耦，但语义强绑定。典型结构如下：
- 池内部维护一个
ConcurrentLinkedQueue<t></t>存闲置对象 - 持有一个
Semaphore，初始 permits = 最大并发数（如 100） -
acquire()方法：先semaphore.acquire()，再从队列取对象；若队列空，可新建（需限制总实例数）或抛异常 -
release(T obj)方法：先重置对象状态（清空缓存、断开引用），再入队，最后semaphore.release()
精准控制上限的实操细节
避免常见偏差，确保“上限”真正生效：
- 禁止在 acquire 失败时绕过 semaphore 直接 new 对象 —— 这会突破上限，应统一走池逻辑或拒绝请求
- 释放必须放在 finally 块中，防止因异常未归还 permit（推荐用 try-with-resources 封装可关闭的池对象）
- 若支持“预热”或“最小保有量”，这些闲置对象不占用 permit；permit 仅约束 正在被业务线程使用的对象数
- 监控指标建议暴露：
semaphore.availablePermits()（空闲许可）、semaphore.getQueueLength()（等待线程数），用于告警积压
富文本场景下的典型适配示例
例如解析一篇含 50 张图片 + 20 个表格的 Markdown 文档，每个图片需独立调用 `ImageProcessor` 实例：
- 设 `ImageProcessorPool` 的 semaphore permits = 8 → 最多 8 个图片并行处理
- 前端上传 100 张图，后端按顺序提交解析任务 → 实际并发始终 ≤ 8，其余任务在 semaphore 队列中等待
- 单个 `ImageProcessor` 实例处理完后 release，立即唤醒一个等待线程，无需额外调度逻辑
不复杂但容易忽略：Semaphore 管的是“并发度”，不是“对象身份”。只要确保每次 acquire/release 成对、无泄漏、不绕过，就能精准钉住当前被借出对象的硬性上限。
