AnyLogic使用Add List Button并行调用不同资源池的报错问题咨询

建模方式合理性判断 #

这种将每个工人单独建模为容量仅0/1的独立资源池、通过调整容量控制可用工人数的方式具备可行性，可以精准实现单个工人维度的停机、状态管控，匹配你之前需要为部分工人单独设置 downtime 的需求，但该方案维护成本较高，资源调用配置容易出现匹配冲突，不属于最优实现方案。

报错原因分析 #

你遇到的报错核心是：动态调整demontage140WorkersPool1容量（将其设为0销毁资源单元）时，该资源池仍有已被代理预留、尚未释放/处理的资源请求，AnyLogic的资源调度机制检测到未完成的预留关联关系，因此抛出内部错误。
从报错日志也能看到，当前待处理的资源请求中仍包含该资源池的申请项，同时列表中存在null:0的无效请求项，进一步干扰了调度逻辑的正常执行。

解决方案 #

• 调整资源池容量前增加前置操作：每次将某资源池容量从1改为0之前，先执行demontage140WorkersPool1.releaseAll()强制释放该池所有已被占用的资源单元，同时执行对应Seize块的seize.cancelAllRequestsFor(demontage140WorkersPool1)方法，取消所有针对该池的待处理资源请求，确认无关联请求后再修改容量。
• 优化资源请求列表配置：使用Add List Button生成资源请求列表时，仅将当前容量为1的有效资源池加入列表，过滤掉容量为0的资源池，避免null:0这类无效项出现在请求列表中干扰调度。
• 可选优化方案：可替换为单资源池+自定义筛选的更简洁方案：仅保留1个总资源池，容量设置为最大工人数，为每个工人资源单元新增isEnabled布尔类型参数，需要为某工人设置停机/不可用状态时，将对应单元的isEnabled设为false，在Seize块的资源选择条件中配置unit.isEnabled == true即可实现仅调度可用工人，无需维护多个独立资源池，也不会出现动态改容量引发的调度冲突。

内容的提问来源于stack exchange，提问作者Mohammad Hasan N.