collectors.partitioningby仅支持二分，需将多级报警映射为布尔逻辑：如用(a->a.getlevel()==critical||a.getlevel()==high)分离“需立即响应”与“可延后处理”，再嵌套groupingby细分；海量数据时应过滤、分批、慎用并行流。
用 Collectors.partitioningBy 对海量报警变量按等级自动分类，核心在于：它只支持二分（true/false），所以**必须先把多级报警（如 CRITICAL、HIGH、MEDIUM、LOW）映射为布尔逻辑**，再组合使用——单次 partitioningBy 不足以处理多级，但配合嵌套或后续分组可高效落地。
明确报警等级的布尔化策略
partitioningBy 接收一个 Predicate<t></t>，返回 true 或 false。不能直接“分四类”，但可以设计分层判断逻辑：
-
一级分流：用
partitioningBy(alarm -> alarm.getLevel() == Level.CRITICAL)分出“是否严重” -
二级嵌套：对非 CRITICAL 的子集，再用
partitioningBy判断是否 >= HIGH；或改用groupingBy做多值分组（更自然） -
推荐做法：用
partitioningBy快速分离“需立即响应”（CRITICAL + HIGH）和“可延后处理”（其余），再在各自分支内细分
实战代码：两级分区 + 内部分组
假设报警对象 Alarm 有 level 字段（枚举 Level {CRITICAL, HIGH, MEDIUM, LOW}）：
Map<boolean map list>>> classified = alarms.stream()
.collect(Collectors.partitioningBy(
a -> a.getLevel() == Level.CRITICAL || a.getLevel() == Level.HIGH,
Collectors.groupingBy(Alarm::getLevel)
));</boolean>
结果：
– classified.get(true) 是 {CRITICAL=[...], HIGH=[...]}
– classified.get(false) 是 {MEDIUM=[...], LOW=[...]}
处理海量数据时的关键优化点
报警量达百万级时，仅靠 Stream 可能 OOM 或慢，需配合：
-
并行流慎用：partitioningBy 本身线程安全，但若 Alarm 对象含共享状态或下游有副作用，避免
parallelStream() -
提前过滤：先用
filter剔除已确认/过期报警，减小数据集 -
流式分批处理：结合数据库游标或文件分块读取，每次处理 1w 条，用
partitioningBy局部分类，再合并统计结果 -
替代方案提示：若纯内存分类且等级固定，用
groupingBy(Alarm::getLevel)更直观；partitioningBy 的价值在于**带语义的二分决策场景**，比如“是否触发短信通知？”
扩展：与业务规则联动的动态分级
等级不完全由枚举决定？例如“CPU > 95% 且持续 2min”才升为 CRITICAL。此时 predicate 可封装规则引擎调用：
PartitioningBy( alarm ->
ruleEngine.evaluate(alarm, "IS_CRITICAL_TRIGGER")
)
保持 partitioningBy 的简洁性，把复杂逻辑下沉到 evaluate 中，便于单元测试和规则热更新。
不复杂但容易忽略：partitioningBy 返回的是 Map<boolean ...></boolean>，key 只有 true/false，别试图往里 put 其他值；多级分类优先考虑 groupingBy，partitioningBy 用在“是/否”有明确业务含义的切口上。
