懒加载并发流技术需融合延迟初始化、按需读取与线程安全复用，专治文件句柄卡顿、fd/内存占用高及初始化失败问题，核心是首次I/O调用才触发昂贵操作。
懒加载并发流技术不是简单地“加个 lazy”，而是把延迟初始化、按需读取、线程安全复用三者严丝合缝地拧在一起。它专治那些一打开就卡顿、占 fd、吃内存、还可能失败的文件句柄——比如 Parquet 元数据解析、加密流上下文建立、GB 级 mmap 映射等。
核心要义：句柄不打开，流不构建，直到第一行真正被消费
昂贵操作必须卡死在首次 read()、getSchema() 或 iterator().next() 这类实际触发 I/O 的调用点上，绝不能出现在构造器、@PostConstruct、static 块或 Bean 初始化阶段。否则并发请求一来，多个线程可能同时触发重复初始化，既浪费资源又破坏语义。
- Parquet 文件：头解析 + row group 偏移计算 → 拖慢首 read，但后续读极快
- AES-GCM 流：证书校验 + 密钥派生 + 上下文初始化 → 耗时百毫秒级，且不可重入
- MappedByteBuffer：mmap 系统调用 → 预留虚拟地址空间，易触发 OOM 或 fd 耗尽
Java 实现：Lazy<Stream> + 并发保护 + 失败即报
推荐用自定义 Lazy<Stream<T>>（非 Lombok 默认 Lazy），内部封装一个可中断、带超时、线程安全的工厂函数：
- 工厂内用 CompletableFuture.supplyAsync(...).orTimeout(3, TimeUnit.SECONDS) 控制初始化耗时
- 失败时明确抛出 IOException("Failed to open /data/feature/v2.parquet: timeout=3s")，不 fallback、不静默
- 返回的 Stream 必须是 stateful 且不可重用；若需多线程并发读同一源，应返回新 Stream 实例（如每次调用 .stream()）
- 句柄对象本身声明为 final，杜绝部分构造后被外部引用
并发场景下的关键防护点
高并发下最容易翻车的是“看似懒、实则抢”：
- 避免在 getter 中做双重检查锁（DCL）——JVM 不保证 volatile 对象的构造完成可见性
- 不要用 synchronized 包裹整个 stream 构建逻辑——会串行化所有首次请求，放大延迟
- 正确做法：用 AtomicReference<Stream<T>> + compareAndSet(null, newStream)，失败则直接返回已成功构建的实例
- 对加密流等有状态对象，确保每个线程拿到的是独立解密上下文，而非共享 cipher 实例
配套能力：预热 + 诊断 + 可降级
生产环境不能靠用户请求“帮我们热身”：
- 提供 POST /admin/streams/warmup?path=/rules/latest.bin 预热端点，发布后自动触发，验证句柄可建、元数据可读
- 暴露 /actuator/metrics/stream.init.time.max 等指标，监控首次初始化 P99 耗时
- 设计降级开关：当初始化连续失败 N 次，自动切换至本地缓存 Schema 或返回空流，避免雪崩
