Flink窗口源码深度解析：从分配器到触发器的完整链路

1. 窗口的底层分类与分配器：先搞清楚“窗口到底是什么”

1.1 从一次“窗口不触发”的深夜排查说起

之前有个实时数仓项目，凌晨2点生产环境突然报警，Kafka 里数据积压，Flink 任务不报错也不消费。翻看日志，发现某个按事件时间开 10 分钟滚动窗口的算子一直不输出结果。查了 watermark、检查了 source 端的空闲分区，最后点开 Web UI 看 Watermark 曲线，才发现问题出在哪儿——但当时我脑子里第一反应不是去猜，而是直接翻窗口相关的源码。因为窗口这种抽象，数据什么时候进窗口、窗口什么时候触发、触发完什么时候销毁，全藏在几个核心类里，不读源码靠猜，只会越排查越偏。

窗口是 Flink 处理无限流的核心抽象。简单说，它就是“把无限的数据流，按某种规则切成有限的数据块”。但这句话背后全是细节。窗口是谁切的？按什么逻辑切的？切完之后谁负责存？存到什么时候触发计算？触发完之后状态还留不留？这些问题分别对应源码里的 WindowAssigner、WindowOperator、Trigger、InternalTimerService 这几个角色。后面几节我会逐个拆。

1.2 四种分配器：Tumbling、Sliding、Session、Global 的源码差异

打开 org.apache.flink.streaming.api.windowing.assigners.WindowAssigner，它是一个抽象类，核心方法是 assignWindows(T element, long timestamp, WindowAssignerContext context)。你传入一条元素和它的时间戳，它返回一个 Collection<W>——注意，是一个集合，也就是说一条数据可以被分配到多个窗口。这就是滑动窗口“重叠”的源头。

Flink 内置了四类分配器：

读这四类实现的源码，你会感受到设计上的差异。滚动窗口和滑动窗口的 assignWindows 都用到了 TimeWindow.getWindowStartWithOffset(timestamp, offset, size) 这个静态方法，它做的事就是算“给定时间戳属于哪个窗口起始位置”。偏移量 offset 是时区相关的东西，默认 0。滑动窗口则在这个基础上循环 for (long start = lastStart; start > timestamp - size; start -= slide) 往回找所有可能覆盖当前时间戳的起始位置。这段代码读懂了，你就明白了为什么 1 小时窗口、5 分钟滑动，一条数据会出现在最多 12 个窗口里——因为 1小时/5分钟 = 12。

会话窗口则复杂得多，它用的是 MergingWindowAssigner，每个元素先创建一个以自己时间戳为起始、start + gap 为结束的候选窗口，然后由 WindowOperator 去合并所有“有交集或首尾相接”的窗口。合并逻辑不是在分配器里做的，它依赖窗口状态里的 MergingWindowSet，这点后面单独说。

1.3 窗口四要素：分配、触发、移除、合并，各自住在哪个类里

读窗口源码，先在大脑里建一张地图。整个窗口机制不是一个大一统的类，而是由四个角色协作完成的：

• 分配（Assign）：WindowAssigner，管的是“数据进哪个窗口”。
• 存储：WindowOperator 里的 windowState，管的是“窗口数据放在状态后端哪个 namespace 下”。
• 触发（Trigger）：Trigger，管的是“什么时候把窗口里的数据推给下游”。
• 清理与合并：Trigger 的 clear 方法 + MergingWindowSet，管的是“窗口结束之后状态怎么释放、会话窗口怎么合并”。

真正干活的容器是 WindowOperator。它同时实现了 OneInputStreamOperator 和 Triggerable，前者让它能处理流式元素，后者让它能处理定时器回调。具体的执行链路我会在下一节展开。

这里先记住一句话：**窗口的触发不是由“窗口满了”决定的，而是由定时器决定的。**事件时间窗口的触发条件，是 watermark 越过了窗口的 maxTimestamp；处理时间窗口的触发条件，是处理时间定时器到了窗口结束时间。Trigger 只是告诉你“这个条件下该不该触发”，真正开着定时器、按时间回调的是 InternalTimerService。

2. WindowOperator 内部工作栈：一条元素进入窗口算子之后发生的完整链路

2.1 processElement 方法的五步流程

WindowOperator 最核心的方法是 processElement(StreamRecord<IN> element)。如果你读过 Flink 的流式计算引擎，会知道每条消息进来都会走这个方法。我把它的逻辑简化成下面这几步，每步对应一个具体的源码调用：

1. 分配窗口：调用 windowAssigner.assignWindows(element.getValue(), element.getTimestamp(), windowAssignerContext)，得到窗口集合 windows。
2. 合并处理：如果分配器是 MergingWindowAssigner，调用 mergeWindows(...) 把需要合并的窗口合并掉，然后拿到合并后的窗口集合。
3. 逐窗口处理：对每个窗口 window，先根据窗口信息构造 namespace（对于 Session 窗口这个 namespace 就是窗口本身，对于时间窗口就是 TimeWindow），然后从状态后端获取或创建该窗口的 windowState。
4. 触发判断：调用 triggerContext.onElement(...)，也就是触发器的 onElement 方法，拿到一个 TriggerResult。
5. 数据写入与结果分发：如果 TriggerResult 包含 FIRE，调用 emitWindowContents(...) 把窗口里的数据聚合并发送出去；如果包含 PURGE，则清理窗口状态。同时把当前元素添加到 windowState 里。

这段代码里最容易被忽略的是第 3 步的“根据窗口构造 namespace”。Flink 的状态（包括窗口状态）是按 key + namespace 隔离的。同一个 key 下，不同窗口的数据互不干扰，靠的就是 namespace 做索引。也就是说，窗口状态本质上是“为每个 key + 每个 window 保存的一份独立状态”，如果你有 100 万个 key、每个 key 的滑动窗口横跨 12 个窗口，那状态后端的条目数就是 1200 万。这是很多窗口任务状态爆炸的根源。后面我会专门写这个坑。

2.2 state 的落地：窗口状态到底存在哪里

WindowOperator 在 open() 方法里有一段类似的初始化代码：

java复制internalWindowState = getStateBackend().createInternalState(
        windowStateDescriptor,
        windowSerializer,
        windowAssigner.getWindowSerializer(config));

这个 internalWindowState 的类型是 InternalAppendingState，实际上保存的是窗口内的 ListState 或 AggregatingState，取决于你用的是 apply、aggregate 还是 reduce。如果你用 aggregate，底层会转成 InternalAggregatingState，每个 key + window 只维护一个累加值；如果你用 apply 或 process 这种需要完整集合的接口，底层就是 InternalListState，每个 key + window 会把所有记录攒在内存/磁盘里。

这里有一个非常重要的性能结论：**用 aggregate 算子，窗口内状态占用和吞吐量不成正比，而用 apply 或 process 接口，状态量会随窗口内数据量线性增长。**实时数仓里动辄几千万条数据的滚动窗口，如果图省事用 apply，大概率会把 TaskManager 堆内存打爆。正确做法是尽量用 aggregate + AggregateFunction，或者自定义 ProcessWindowFunction 配合预聚合。

此外，窗口状态的清理依赖两个机制：一是触发窗口计算时是否 PURGE，二是 Trigger.clear() 是否主动删除状态和定时器。源码里 WindowOperator.clearWindowState(window) 最终会调用 internalWindowState.clear()，同时 clearWindowTimers(window) 会删掉该窗口注册的定时器。这部分逻辑在 onProcessingTime 和 onEventTime 定时器回调里都有触发点。

2.3 窗口的 namespace 设计：为什么 Session 窗口的合并那么难

Session 窗口的 namespace 就是窗口对象本身，而 SessionWindow 和 TimeWindow 都是 Window 接口的实现类。合并时，WindowOperator 依赖 MergingWindowSet 来维护“哪些窗口已经被合并成了哪个新窗口”的映射关系。MergingWindowSet 内部有一份基于 MapState<Window, Window> 的状态，记录每个初始窗口对应的最新窗口。

当一个新元素进来，它会先往 MergingWindowSet 里加入一个候选窗口，然后遍历所有存在窗口，找出所有 overlapping（区间重合或无缝相邻）的窗口，合并成一个新区间。这一步并不是简单的“把 list 合并”，而是要把合并前的所有窗口状态迁移到新区间下，还要通知 Trigger.onMerge(...) 合并定时器和累加器。所以 Session 窗口的计算成本比其他窗口高一个量级，尤其是 gap 较大、窗口数量较多时，MergingWindowSet 的遍历可能成为瓶颈。我在后面的实战坑里会再提。

3. 真正的触发逻辑在定时器里：Trigger 源码剖析

3.1 Trigger 的四个核心接口与 TriggerResult

Trigger 接口的源码不算复杂，但它的每个方法都对应一个关键时机：

java复制public abstract class Trigger<T, W extends Window> implements Serializable {
    public abstract TriggerResult onElement(T element, long timestamp, W window, TriggerContext ctx);
    public abstract TriggerResult onProcessingTime(long time, W window, TriggerContext ctx);
    public abstract TriggerResult onEventTime(long time, W window, TriggerContext ctx);
    public abstract void clear(W window, TriggerContext ctx);
    // 可选：onMerge(W window, OnMergeContext ctx)，用于会话窗口合并
}

其中 TriggerContext 是 Trigger 与外部世界交互的桥梁，它提供了 registerProcessingTimeTimer、registerEventTimeTimer、deleteProcessingTimeTimer、deleteEventTimeTimer 等方法，还暴露了 getCurrentWatermark、getPartitionedState（为每个窗口的独立状态准备）。看到 getPartitionedState，你应该能联想到刚刚说的“每个 key + window 维护一份状态”——Trigger 自己也可以维护窗口级别的状态，比如 CountTrigger 里用来计数。

TriggerResult 是一个枚举，取值是 CONTINUE、FIRE、PURGE、FIRE_AND_PURGE 四个。它决定的是 WindowOperator 在触发回调之后，要不要把窗口数据发射出去，以及要不要顺手清掉状态。这里有个细节：**FIRE 和 FIRE_AND_PURGE 的区别在于，FIRE 只发射数据、不清窗口状态，FIRE_AND_PURGE 在发射数据的同时清空窗口状态。**如果只用 FIRE，窗口状态会一直留到后续某个时刻被显式清理；如果直接用 FIRE_AND_PURGE，就不会有迟到数据进入窗口的机会了。所以 allowedLateness 与 TriggerResult 的组合是个需要小心的设计点。

3.2 EventTimeTrigger：为什么“watermark 过了 maxTimestamp”才触发

先看 EventTimeTrigger 的简版源码：

java复制public class EventTimeTrigger extends Trigger<Object, TimeWindow> {
    @Override
    public TriggerResult onElement(Object element, long timestamp, TimeWindow window, TriggerContext ctx) {
        if (window.maxTimestamp() <= ctx.getCurrentWatermark()) {
            return TriggerResult.FIRE;
        }
        ctx.registerEventTimeTimer(window.maxTimestamp());
        return TriggerResult.CONTINUE;
    }

    @Override
    public TriggerResult onEventTime(long time, TimeWindow window, TriggerContext ctx) {
        return time == window.maxTimestamp() ? TriggerResult.FIRE : TriggerResult.CONTINUE;
    }

    @Override
    public void clear(TimeWindow window, TriggerContext ctx) {
        ctx.deleteEventTimeTimer(window.maxTimestamp());
    }
}

注意看 onEventTime 里的判断是 time == window.maxTimestamp()，也就是说，只有当定时器回调的时间恰好等于窗口的最大时间戳时，才会 FIRE。这个最大时间戳是怎么算的？TimeWindow.maxTimestamp() 的实现是 end - 1。比如一个 [09:00, 09:10) 的窗口，事件时间的最大合法值是 09:09:59.999，watermark 越过它之后，onEventTime 才会触发窗口计算。

那 WindowOperator 是怎么把注册好的定时器跟这个触发关联起来的？在 onElement 里，如果窗口发现当前 watermark 还没到 maxTimestamp，就会 registerEventTimeTimer(window.maxTimestamp()) 注册一个定时器。水位线一旦推进到 maxTimestamp + 1，InternalTimerService.advanceWatermark 会扫描事件时间定时器队列，把到期的定时器一个个回调到 onEventTime。所以，事件时间窗口的触发，本质上是 watermark 驱动的事件时间定时器回调。中间任何一个环节卡住（source 端水位线不更新、某个算子不转发 watermark、定时器队列异常），窗口就永远不会触发。

3.3 ProcessingTimeTrigger、CountTrigger 与自定义 Trigger 的踩坑经验

处理时间窗口的 ProcessingTimeTrigger 也有一行关键逻辑：

java复制@Override
public TriggerResult onProcessingTime(long time, TimeWindow window, TriggerContext ctx) {
    return TriggerResult.FIRE;
}

它不管 time 是不是 window.maxTimestamp()，只要处理时间定时器被回调，就直接 FIRE。这其实是基于一个假设：注册处理时间定时器的时候，就是注册在 window.maxTimestamp() 上。但如果你在自定义 Trigger 里乱注册定时器，这个 FIRE 可能不是你想的语义。

CountTrigger 则完全不同，它用的不是时间而是计数：

java复制public TriggerResult onElement(Object element, long timestamp, W window, TriggerContext ctx) {
    ReducingState<Long> count = ctx.getPartitionedState(countStateDescriptor);
    count.add(1L);
    if (count.get() >= maxCount) {
        count.clear();
        return TriggerResult.FIRE;
    }
    return TriggerResult.CONTINUE;
}

我建议任何刚接触 Flink 窗口的读者，至少亲手改一次 Trigger，实现一个“每 10 条数据或者每分钟触发一次，先到先得”的逻辑。你会在写的过程中发现一个坑：如果状态不清，count 会无限累加；如果 clear 时机不对，可能把还没触发完的数据清掉。这些只有动手才会印象深刻。

4. 滑动窗口为什么窗口数量爆炸：窗口复用与重叠窗口源码分析

4.1 SlidingEventTimeWindows.assignWindows 的核心算法

滑动窗口是生产环境里用得最多、也是最容易出问题的窗口类型。打开 SlidingEventTimeWindows.assignWindows：

java复制public Collection<TimeWindow> assignWindows(Object element, long timestamp, WindowAssignerContext context) {
    if (timestamp > Long.MIN_VALUE) {
        if (staggerOffset != null) {
            // 处理并行度相关的错峰逻辑
        }
        List<TimeWindow> windows = new ArrayList<>((int) (size / slide));
        long lastStart = TimeWindow.getWindowStartWithOffset(timestamp, offset, slide);
        for (long start = lastStart;
             start > timestamp - size;
             start -= slide) {
            windows.add(new TimeWindow(start, start + size));
        }
        return windows;
    } else {
        throw new RuntimeException("Record has Long.MIN_VALUE timestamp ...");
    }
}

这个算法的核心是：先找到当前时间戳在“滑动步长”上的最后一个窗口起始位置 lastStart，然后不断往前跨 slide 找下一个窗口，直到窗口的结束时间仍然覆盖当前时间戳为止。如果 size=1小时、slide=5分钟，那么 size / slide = 12，你最多会得到 12 个窗口。如果一条数据的时间戳恰好落在边界，可能少于这个数，但不会超过。

这里有个容易被忽略的边界：当 slide > size 时（比如 10 分钟窗口、15 分钟滑动），会出现“某些时间段没有窗口覆盖”的情况，数据会进入一个或零个窗口。这种用法在业务上通常是“最近 10 分钟、每 15 分钟统计一次”，听上去合理，但你要确认下游真的能接受中间的空窗期。

4.2 重叠窗口带来的状态放大：12 个窗口不是 12 份数据

很多人以为滑动窗口“窗口数多”只是计算次数多，其实最要命的是状态量被放大。前面提过，窗口状态是按 key + window 存储的。一个 1 小时窗口、5 分钟滑动的任务，每条数据要同时写入 12 个窗口。如果你用的是 ListState（比如 apply 接口），那每条数据在状态后端里会存 12 份。假设一天的原始数据量是 10 亿条，状态写入量就是 120 亿条——这个量级足以拖垮 RocksDB。

生产里我见过的解决思路有三种：

• 尽量用 aggregate + AggregateFunction，让每个窗口只维护一个累加器，虽然每个窗口还是一份独立状态，但状态大小从“数据量”降为“累加器大小”。
• 如果窗口逻辑需要完整元素集合，可以考虑先用 aggregate 做预聚合，再用 ProcessWindowFunction 处理细节。Flink 的 agg + process 组合可以做到预聚合后只保留累加值。
• 如果业务上允许一定误差，用 Tumbling 窗口近似滑动窗口的效果（比如每 5 分钟开一个 10 分钟滚动窗口，各自独立，最后在下游做拼接或去重），能把状态量缩小一个数量级。

“用滚动窗口拼出滑动窗口效果”在生产中非常常见，代价是逻辑变复杂、数据会有重叠或延迟，但收益是 RocksDB 的压力大幅下降。

4.3 窗口起始时间为什么是整点：getWindowStartWithOffset 的源码细节

读完滑动窗口的循环，你可能会好奇 TimeWindow.getWindowStartWithOffset 它是怎么算窗口起始时间的：

java复制public static long getWindowStartWithOffset(long timestamp, long offset, long windowSize) {
    return timestamp - (timestamp - offset + windowSize) % windowSize;
}

这个公式保证窗口起始时间总是 offset + n * windowSize 这样的等差数列。默认 offset = 0，所以时间窗口的起始时间永远是整点、整分、整秒。如果你要处理非整点的窗口（比如从早上 8 点 30 分开始算一小时一个窗口），就需要在 TumblingEventTimeWindows.of(...) 之外额外指定 offset。Flink 没有直接暴露这种 API，通常需要通过自定义分配器或 withOffset 来实现，但看过源码公式后，你自己实现一个也不难。

5. 事件时间、水位线与迟到数据：源码里最难啃的一块

5.1 watermark 是怎么推进窗口触发的：InternalTimerService 的运转原理

事件时间窗口触发不是 WindowOperator 自己盯着 watermark，而是由 InternalTimerService 统一管理的。每个窗口在注册事件时间定时器时，会把 (namespace, timestamp) 丢进一个优先队列。水位线推进时，advanceWatermark 方法会把所有 timestamp <= 新水位线 的定时器弹出来，依次触发回调。

这里的实现细节值得看：InternalTimerServiceImpl 里，定时器并不是简单的 PriorityQueue<Timer>，而是按 key 分组存储的，还带有一个 TimerHeap（堆结构）。如果你有大量 key 同时触发大量定时器，这个堆的压力会非常大。这也是为什么生产上要尽量避免“水位线突然暴涨”导致成千上万个窗口同一时刻被触发——那瞬间的 CPU 和 IO 可能导致整个作业卡顿。

有一个容易被忽略的点：InternalTimerService 在创建时会检查当前 key 是否为 null。全局窗口（GlobalWindows）或未做 keyBy 的操作，无法注册定时器，这在报错信息里有明确提示。如果你发现自己写了一个全局窗口 + 事件时间 + 自定义 Trigger，却一直跑不起来，八成是踩了这个限制。

5.2 allowedLateness 背后隐藏的两次注册机制

allowedLateness 的作用是：允许窗口在 maxTimestamp 之后仍然接收迟到数据，直到 maxTimestamp + allowedLateness 才彻底关闭。实现上，WindowOperator 会在 onElement 里额外注册一个事件时间定时器：

java复制if (window.maxTimestamp() + allowedLateness <= ctx.getCurrentWatermark()) {
    // 迟到的数据，扔进 side output
    sideOutputLateData(outputTag, record);
} else if (window.maxTimestamp() + allowedLateness <= currentProcessingTime) {
    // 处理时间窗口的迟到数据处理
} else {
    // 注册延迟关闭定时器
    ctx.registerEventTimeTimer(window.maxTimestamp() + allowedLateness);
}

注意这个“延迟关闭定时器”的作用：它不是用来触发计算的，而是在到了 maxTimestamp + allowedLateness 时，负责调用 trigger.clear() 清理窗口状态和定时器。也就是说，如果你设置了 allowedLateness = 5分钟，那么窗口的数据会被保留 5 分钟，计算可以触发多次（第一次是 watermark 越过 maxTimestamp，之后每次有迟到数据落在窗口里，只要它还活着，就可能再次触发），直到 5 分钟后的定时器把它彻底清掉。

这个机制本身就解释了“为什么早到/迟到数据不能无限等、为什么窗口状态会多存活一段时间”。但很多人在生产里只看结果，没想过清理是靠一个额外定时器做的，导致遇到“窗口状态迟迟不释放”时无从下手。实际上你只要检查 maxTimestamp + allowedLateness 对应的定时器是否被注册、是否被触发即可。

5.3 迟到数据的侧输出：sideOutputLateData 的正确用法

迟到数据不等于不要的数据。Flink 提供了 sideOutputLateData(outputTag) 方法，把那些已经超过 maxTimestamp + allowedLateness 的记录丢给一个旁路输出，而不是直接丢弃。这个机制在实时数仓里很实用——比如数仓里需要统计“准时到达的数据”和“迟到数据”分开处理，迟到数据可以单独走一套补偿流程。

写法上很简单：

java复制OutputTag<MyEvent> lateTag = new OutputTag<MyEvent>("late") {};
DataStream<AggResult> result = input
    .keyBy(...)
    .window(TumblingEventTimeWindows.of(Time.minutes(5)))
    .allowedLateness(Time.minutes(1))
    .sideOutputLateData(lateTag)
    .aggregate(new MyAggFunction());

DataStream<MyEvent> lateStream = result.getSideOutput(lateTag);

我第一次用这个功能时踩过一个坑：OutputTag 的泛型必须和元素类型完全一致，如果侧输出流的类型和主输出流不一致，getSideOutput 编译不报错但运行时报类型错误。而且为了保证侧输出里的数据做后续处理时仍然有时间戳，建议在侧输出流上再补一次 assignTimestampsAndWatermarks。这个细节文档里不会强调，但做实时数仓的同学应该深有体会。

5.4 处理时间窗口为什么通常不用在“乱序”场景

处理时间窗口，也就是 ProcessingTimeTrigger 对应的场景，它不关心事件时间戳，不关心 watermark，到达算数。因此它天然没有乱序问题，但也因此无法处理“业务事件发生时间”比“到达系统时间”更早的情况。

源码里处理时间窗口的事件时间定时器注册逻辑很弱：ProcessingTimeTrigger.onElement 直接注册当前时间对应的处理时间定时器，不检查迟到。而 WindowOperator 在处理处理时间窗口时，会把窗口的 maxTimestamp 设置为“当前处理时间”对齐到窗口大小，然后定时器到点就触发。所以你在实时大屏里看到“最近 5 分钟成交额”，用的通常是处理时间窗口，因为它快且无乱序代价，能保证实时刷新。

但如果你想用处理时间窗口做“离线复盘”，那数据会完全对不上业务时间，这是设计问题，不是 bug。我见过不少初级工程师把处理时间窗口当成事件时间窗口用，最后数据对不上账，来问我的时候第一句就是“为什么窗口不触发”，其实窗口早就触发了，只是触发的时间轴跟业务时间轴错位了。这个认知差异，建议所有读窗口源码的人认真体会。

6. 读完源码后我总结的五个高频坑和排查路径

6.1 坑一：watermark 不推进，窗口永远不触发

现象：设置了事件时间窗口，但下游一直没有输出，作业整体延迟越来越高。

排查路径：看 Web UI 里每个算子实例的 Watermark 是否存在 Gap。如果某个并行子任务的 Watermark 始终停留在 Long.MIN_VALUE，说明这个子任务没有收到任何 watermark，通常是 source 端某个分区没有进行 assignTimestampsAndWatermarks，或者并行度大于 source 分区数、某个子任务没有数据。还有一种常见情况是 source 数据里有一部分事件时间戳是 Long.MIN_VALUE，导致 watermark 被拉低，窗口无法触发。

结论：不要把 assignTimestampsAndWatermarks 放在窗口算子之后，一定要在 source 端尽早指定。如果 source 有空闲分区，要设置 withIdleness（空闲分区超时机制），否则会拖住整个 watermark 前进。

6.2 坑二：allowedLateness 设置过大，窗口状态迟迟不释放

现象：允许迟到 30 分钟，结果作业状态持续增长，RocksDB 的目录越来越大，GC 也频繁。

原因：allowedLateness 越大，窗口的存活时间就越长。源码里窗口的清理依赖 maxTimestamp + allowedLateness 时刻的定时器，所以 10 分钟窗口 + 30 分钟 lateness，意味着窗口数据要留 40 分钟。如果 key 的基数大、窗口数量多，这个状态开销非常可观。

结论：allowedLateness 设置前，先评估状态后端容量。建议用 state TTL 或显式的定时器管理来兜底，防止某个窗口状态因为异常没被清理而永久残留。Flink 的 WindowOperator 已经做了“延迟清理定时器”，但如果你自己在自定义 Trigger 里没有合理注册清理逻辑，状态还是会漏。

6.3 坑三：会话窗口合并时数据串窗口

现象：Session 窗口的 gap 设了 5 分钟，业务上两个会话非常接近也可能被合并成一个窗口，导致输出结果跟预期不一致。

源码层面原因：EventTimeSessionWindows 的合并条件是“两个窗口的区间有重叠或无缝相邻”。但这里的相邻判断用的是左闭右开区间，头尾相接的两个窗口也会被合并。比如 [10:00, 10:05) 和 [10:05, 10:10) 会被当成一个 [10:00, 10:10)，因为 10:05 == start + gap 被算成相邻。这在某些业务语义下是不符合预期的，但符合 Flink 源码的实现。

建议：如果业务上不允许头尾衔接合并，需要自定义 WindowAssigner 继承 MergingWindowAssigner，把合并条件改成“严格重叠”（windowStart < anotherWindowEnd && anotherWindowStart < windowEnd）。

6.4 坑四：滑动窗口把状态打爆

这类问题在第 4 节已经详细展开，这里再补充一个排查工具：在 Flink Web UI 的 TaskManager 页面看 RocksDB 或堆内存的 state.size。如果发现某个算子的状态量级远大于预估的数据量，优先怀疑是滑动窗口 + ListState 导致的状态放大。最简单的验证方法：把窗口改成 aggregate，再观察状态量是否下降。如果下降明显，那问题就定位在窗口接口的选择上。

6.5 坑五：自定义 Trigger 定期清理不生效

现象：自定义 Trigger 里实现了“每 100 个元素触发一次”，但是触发后窗口数据仍旧残留，下一次触发时数据重复。

原因：触发后如果没有把计数器状态清零（比如 ClearingState.clear()），第二次触发时计数仍然是累计值或者从上次值继续加，导致逻辑错乱。同时，如果你用的时 TriggerResult.FIRE 而不是 FIRE_AND_PURGE，窗口的 list state 不会被清理，下一次触发会包含历史数据。

结论：自定 Trigger 时，先想清楚 TriggerResult 的语义。如果需要“触发后清空窗口内的数据”，应该用 FIRE_AND_PURGE；如果还需要保留状态等待后续定时清理，用 FIRE 并额外注册清理定时器。但大多数业务场景里，FIRE_AND_PURGE 更符合直觉。

7. 读完源码之后再回头看这四个设计点

窗口源码读完之后，回头看会发现 Flink 的设计思路其实非常统一：通过分配器把无限流切块，通过定时器精确控制触发时机，通过状态后端做数据持久化，通过 Trigger 把“业务需要的触发策略”与“窗口内部的调度机制”解耦。如果你只停留在 API 层面，很容易把窗口当成一个黑盒；但只要你读过一遍 WindowOperator、Trigger、InternalTimerService、MergingWindowSet 这几个核心类，再遇到窗口不触发、状态爆炸、迟到的数据处理得不干净这类问题，你会优先从源码逻辑入手，而不是靠运气换参数。

我在实际工作中还发现一个技巧：排查窗口问题时，不要只盯日志，可以给窗口算子挂上 Side Output，把手动判断的迟到数据和异常数据都输出出来，观察它们最终去了哪里。这个做法在 Flink 实时数仓项目里几乎成了标配——因为它能让你在数据层面看到“窗口算子的边界到底在哪里”，而不只是猜。

最后再分享一个小经验：窗口源码最容易读晕的地方是 Trigger 和 InternalTimerService 之间的调用关系，建议手里准备一张纸，把 processElement -> onElement -> TriggerResult -> registerEventTimeTimer -> advanceWatermark -> onEventTime -> emitWindowContents -> clearWindowState 这条链路画出来，你才会真正理解 Flink 窗口的“来龙去脉”。一旦这链路里的每一步都能对应到源码里的一个方法，你对窗口的理解就已经超过绝大多数人了。