流式无“boundary flushing”标准术语，实为在逻辑边界（如窗口关闭、惰性执行终点、特征生成节点）主动触发物化、状态清空或资源释放，以实现内存平稳基线。
流式的边界数据清除（Boundary Flushing）并不是一个标准术语，当前主流技术栈中——无论是流式计算框架（如 Flink、Spark Structured Streaming）、流式数据库（如 Materialize、Doris Stream Load），还是生物信息或地理空间领域——均没有“Boundary Flushing”这一规范概念。你提到的表述，极可能是将多个不同领域的术语发生了混合迁移：
- “Boundary”易联想到地理空间中的 Boundary Clean（边界清理，如 ArcGIS 的
BoundaryClean工具）； - “Flushing”常用于流系统中指代 缓存清空、缓冲区提交或物化点触发（如 Flink 的
checkpointing、Polars 的sink_parquet()）； - “长周期流的内存平稳基线”则明确指向流式处理中长期运行不OOM、内存占用收敛可控的核心诉求。
因此，真正有效的解法不是寻找一个叫“Boundary Flushing”的功能，而是在流式执行链路的关键边界处，主动插入轻量、确定性、非阻塞的物化/截断/释放动作，从而切断隐式引用、防止中间状态累积、重置局部内存压力。以下是可直接落地的三类实操策略：
用惰性执行边界替代 eager 物化边界
Polars、DuckDB 等现代分析引擎已验证：只要全程保持 LazyFrame 链，所有变换（.filter()、.with_columns()）都只是计划节点，不分配实际内存。真正的内存峰值只出现在终端动作——collect() 或 sink_*()。
- ✅ 正确做法：用
pl.scan_parquet(...).filter(...).with_columns(...).sink_parquet("out.parquet") - ❌ 错误做法：
df = pl.read_parquet(...); df.filter(...).select(...).write_parquet(...)—— 每一步都加载全量数据到内存
这相当于在「逻辑计算边界」上设置一道闸门：上游数据未被请求，下游绝不加载。内存基线由输入分块大小 + 执行器并发度决定，而非全量数据规模。
在时间/事件窗口边界强制 checkpoint & state drop
Flink / Kafka Streams 等有状态流引擎中，“边界”是天然存在的：滚动窗口、会话窗口、水位线（Watermark）推进点。这些点就是最安全的 flushing 时机：
- 启用增量 Checkpoint（RocksDB backend + changelog enabled），避免每次全量刷盘；
- 对仅需最终结果的场景（如每小时 UV 统计），配置
state.ttl或使用WindowedStream.apply(...).allowedLateness(Time.seconds(0))，让过期窗口状态自动释放； - 关键技巧：用
KeyedProcessFunction在onTimer()中显式调用ctx.timerService().deleteEventTimeTimer(...)+state.clear()，在窗口关闭瞬间清空对应 key 的全部状态。
此时，“边界”即语义完成点；“flushing”即状态裁剪动作。内存不再随运行时长线性增长，而稳定在「最大并发窗口数 × 平均窗口状态大小」水平。
对高维稀疏特征流做在线 embedding 截断与冷热分离
推荐系统长周期流（如实时用户行为流 → 实时特征 → 实时召回）中，ID 类特征交叉（如 user_id × item_id）极易引发 embedding 表爆炸，造成 PS 节点内存持续爬升。这不是 GC 能解决的问题，必须在特征生成边界做主动控制：
- 在特征工程层插入 Cardinality Limiter：对每个 ID 组合字段统计频次，仅保留 top-K 高频组合，其余映射为
<unk></unk>； - 使用 LFU Cache + TTL 管理 embedding lookup 表：例如 PyTorch 的
torchrec支持EmbeddingBagCollection配合ManagedCollisionModule，自动淘汰低频 ID； - 更进一步：将 long-tail ID 流路由至 CPU-only embedding server，GPU 只服务 hot-ID 子集 —— 这本质是在计算资源边界上做 flushing。
这样，embedding 内存占用不再发散，而收敛于业务定义的“热域规模”，形成可预测的平稳基线。
以上三类方法，共同特点是：不依赖全局 GC，不等待 runtime 自动回收，而是在语义清晰、副作用可控的逻辑边界上，主动触发一次确定性释放。它比任何“自动边界清理”更可靠，也比调大 JVM Heap 更治本。
