处理告警状态：选Map<locationId,Map<alarmId,alarm>>还是拼接双Key的Map？

嵌套Map方案（Map<locationId, Map<alarmId, alarm>>） #

优势 #

• 业务逻辑更直观：完全对应「位置-告警」的层级关系，代码可读性强，后续维护人员能快速理解数据结构的含义。
• 批量操作效率高：如果需要获取某个location下的所有告警，直接取出内层Map即可，无需遍历整个大Map筛选Key，节省性能开销。
• 无Key冲突风险：不用担心locationId或alarmId包含分隔符（比如你用的"-"）导致的Key歧义问题——比如locationId为"loc-1"、alarmId为"2"，和locationId为"loc"、alarmId为"1-2"，拼接后Key完全相同，但嵌套Map能彻底避免这种数据覆盖的隐患。

劣势 #

• 层级稍多，取值时需要两次索引（lastState[locationId][alarmId]），写法比单层Map略繁琐。
• 序列化/反序列化时，需要处理嵌套结构，部分缓存或存储组件对嵌套Map的支持可能不如单层Map直接。

拼接Key的单层Map方案（Map<locationId+alarmId, alarm>） #

优势 #

• 结构扁平：只有一层Map，取值时只需一次索引，代码写法更简洁。
• 序列化更简单：单层Map的序列化、反序列化逻辑通常更直接，适配大多数存储或缓存场景。

劣势 #

• Key冲突风险高：一旦locationId或alarmId包含拼接用的分隔符，就会出现不同(locationId, alarmId)对对应同一个Key的情况，直接导致数据错误。
• 批量操作成本高：如果要获取某个location下的所有告警，必须遍历整个Map的所有Key，逐个拆分判断是否属于目标location，性能开销大。
• 可读性差：拼接后的Key无法直观体现业务含义，维护时需要额外理解Key的拼接规则，增加认知成本。

结论 #

如果你的业务场景中存在按location批量操作告警的需求，或者无法确保locationId和alarmId不会包含分隔符，嵌套Map方案是更优选择——它更安全、更贴合业务逻辑，后续维护成本更低。

如果只是单一的按(locationId+alarmId)维度查询告警，且能100%保证拼接后的Key不会重复，拼接方案也可以用，但从长期维护和扩展性来看，嵌套Map的适用性更强。

内容的提问来源于stack exchange，提问作者Alexandru Antochi