Strict模式下Lambda易引发隐式引用泄漏，需避免捕获this/ThreadLocal、显式传参替代线程局部访问、用TTL跨线程传递上下文、采用静态方法引用及定义退出契约。
在 strict 模式（如 JavaScript 严格模式、Java 的 SecurityManager 已弃用但等效沙箱策略，或 Android 的受限执行环境）下，高阶 Lambda 与线程上下文的组合极易引发隐式引用泄漏——尤其当 Lambda 捕获外部对象（如 this、ThreadLocal 变量、闭包状态）并被异步调度、跨线程传递或长期缓存时。
明确 Lambda 的生命周期边界
Lambda 不是“无状态函数”，而是闭包对象。一旦捕获了非基本类型变量（尤其是宿主对象、上下文容器、ThreadLocal 实例），其存活周期就与 Lambda 实例强绑定。
- 避免在 Lambda 中直接捕获
this或 Activity/Service 实例（Android 场景）；改用弱引用包装或提取必要字段值（如id、token）传入 - 若需访问线程局部状态（如用户身份、请求 ID），不要在 Lambda 内部调用
ThreadLocal.get()—— 因为执行时可能已切换线程；应在创建 Lambda 前显式读取并作为参数传入 - 对异步回调类 Lambda（如
CompletableFuture.thenApply、RxJava 的map），确保其不持有对 UI 组件、Fragment、ViewModel 的强引用；可结合WeakReference或使用lifecycleScope（Android）自动绑定生命周期
隔离 ThreadLocal 上下文传递
ThreadLocal 在线程池复用场景下天然易泄漏，而 strict 沙箱通常禁止反射、禁止动态类加载，使常规清理手段受限。
- 绝不在线程池中直接使用未清理的 ThreadLocal：每次任务结束前必须调用
remove()，且应放在try-finally块中，不能依赖线程销毁 - 如需跨线程传递上下文（如从主线程到 IO 线程），禁用
inheritableThreadLocals（默认不继承），改用显式透传机制：例如封装成ContextCarrier对象，通过参数或ExecutorService.submit(Runnable, context)方式注入 - 生产环境推荐使用
TransmittableThreadLocal（TTL）替代原生 ThreadLocal，它支持在ForkJoinPool、ThreadPoolExecutor等场景下自动传播和清理，且兼容沙箱限制（无反射黑魔法）
沙箱内资源与引用的主动裁剪
strict 模式下，很多运行时干预手段（如 System.gc()、sun.misc.Unsafe）被禁用，因此泄漏防控必须前置、静态、可验证。
- 为所有高阶 Lambda 定义明确的“退出契约”：例如返回
AutoCloseable接口，或约定执行后调用.dispose()方法释放闭包持有的资源 - 在构建 Lambda 时，使用静态方法引用（
ClassName::methodName）替代匿名内部类或捕获型 Lambda，可彻底消除对外部对象的隐式引用 - 对敏感上下文（如加密密钥、用户凭证），避免存入 ThreadLocal 或闭包；改用短期有效的 token + 后端校验，或使用
java.security.AccessControlContext进行权限上下文隔离（JVM 级沙箱支持）
安全不是靠沙箱兜底，而是靠设计约束。在 strict 环境下，每个 Lambda 都应视为一个微型有界上下文——它知道什么、能访问什么、何时失效，都必须清晰可声明、可审计、可终止。
