Stream.peek() 不改变流元素，仅用于轻量监控（如日志、计时），需终端操作触发；阶段耗时需前后peek配合原子变量记录，推荐封装TimingPeek工具类实现可复用计时，并注意并行流乱序、线程安全及生产环境日志采样。
stream.peek() 本身不改变流元素，但可以在不干扰逻辑的前提下“窥探”每个元素经过时的状态。它适合插入轻量级监控点，比如打日志、计时、采样统计。但要注意：peek() 只在元素被消费时触发，且**不会强制执行流**——必须有终端操作（如 collect、foreach、count）才会真正运行。
用 peek() 搭配 AtomicLong 或 ThreadLocal 实现阶段耗时记录
单个 peek() 无法直接测“阶段耗时”，因为它是按元素逐个调用的。正确做法是：在每个关键处理步骤前后各加一个 peek()，用原子变量记录起止时间，再按元素 ID 或批次聚合耗时。
- 为每个流元素生成唯一追踪 ID（如 UUID 或递增序号），放在包装对象里，贯穿整个链路
- 用 AtomicLong startNs 记录进入某阶段的纳秒时间，在第一个 peek() 中存入元素上下文；在下一个 peek() 中读取并计算差值
- 避免在 peek() 中做阻塞或复杂计算，否则会拖慢整个流，甚至破坏并行流的行为
典型监控链路示例（含耗时记录）
假设你有一条流：从原始字符串 → 解析为对象 → 过滤无效项 → 转换为 DTO → 聚合统计。你想知道每一步对每个元素花了多久：
AtomicLong parseStart = new AtomicLong();
AtomicLong filterStart = new AtomicLong();
AtomicLong dtoStart = new AtomicLong();
<p>List<Result> results = lines.stream()
// 阶段1：解析前打点
.peek(line -> parseStart.set(System.nanoTime()))
.map(line -> {
var parsed = parseLine(line); // 实际解析逻辑
long cost = System.nanoTime() - parseStart.get();
log.debug("parse-cost: {} ns for {}", cost, line);
return parsed;
})
// 阶段2：过滤前打点
.peek(obj -> filterStart.set(System.nanoTime()))
.filter(obj -> isValid(obj))
.peek(obj -> {
long cost = System.nanoTime() - filterStart.get();
log.debug("filter-cost: {} ns for {}", cost, obj.id());
})
// 阶段3：转换前打点
.peek(obj -> dtoStart.set(System.nanoTime()))
.map(this::toDto)
.peek(dto -> {
long cost = System.nanoTime() - dtoStart.get();
log.debug("dto-convert-cost: {} ns for {}", cost, dto.id());
})
.collect(Collectors.toList());更健壮的做法：封装成可复用的监控工具类
手动写一堆 AtomicLong 易出错、难维护。可以封装一个 TimingPeek 工具，自动绑定阶段名和计时上下文：
- 定义一个轻量包装类
Timed<t></t>，持原始元素 + 当前阶段名 + 开始时间戳 - 提供静态方法
TimingPeek.before("parse")返回一个 peek Consumer，把元素转为 Timed 并记录时间 - 提供
TimingPeek.after("parse")在后续 peek 中读取并打印耗时，再解包回原对象 - 支持 SLF4J MDC，把耗时写入日志上下文，方便链路追踪系统（如 SkyWalking、Zipkin）采集
注意事项与避坑点
peek() 是调试利器，但不是性能分析替代品。真实压测需配合 JFR、AsyncProfiler 等工具：
- 并行流中 peek() 的执行顺序不确定，耗时数据可能乱序，但单个元素的阶段内耗时仍准确
- 不要在 peek() 中修改流中元素状态（尤其是共享对象），可能引发竞态或意外副作用
- 如果流被短路（如 findFirst + filter），peek() 可能只触发部分元素，日志量少于预期，属正常行为
- 生产环境慎用高频率日志（如每元素都打 INFO），建议用 DEBUG 级别 + 条件采样（如每千条记一次）
