内部类本身不隐式持有锁，非静态内部类因隐式持有外部类this引用，可能引发锁竞争、死锁或构造期逸出；应优先使用静态内部类，或显式传参、ThreadLocal、不可变对象等方案规避风险。
内部类在多线程中“隐式持有锁”这个说法其实不准确——内部类本身不会自动持有锁，真正的问题是非静态内部类会隐式持有所属外部类实例的引用（即 this 引用），而如果这个外部实例正在被同步块或 synchronized 方法保护，就可能引发意外的锁竞争、死锁风险，甚至构造期逸出。所谓“避免隐式持有锁”，本质是避免因内部类对外围实例的强引用，导致不该共享的状态被暴露或阻塞。
明确区分静态与非静态内部类
非静态内部类（包括匿名类、局部类）编译后会自带一个隐式字段，指向外围类实例。一旦该内部类被用于多线程场景（如作为 Runnable、监听器、回调），就等于把外围对象“发布”出去了——哪怕你没显式传参。
- 若外围类实例本身是线程不安全的，且其方法用了 synchronized，那么多个线程通过内部类访问它时，可能意外串行化执行，拖慢吞吐
- 更严重的是：在构造函数里 new Thread(new Runnable() { ... }) 这类写法，会让 this 在未初始化完成时就被子线程看到，造成逸出
优先使用静态内部类
静态内部类不持有外围实例引用，天然规避 this 逸出和隐式耦合问题。它适合封装工具逻辑、延迟初始化单例（如 SingletonHolder）、或定义纯数据载体。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 单例场景中，
private static class SingletonHolder只依赖 JVM 类初始化的线程安全性，不涉及任何锁 - 若需访问外部状态，显式传入所需参数（如配置、回调函数），而不是依赖隐式 this
- 避免把静态内部类声明为 public，防止被外部提前触发类加载
非静态内部类必须谨慎使用
只有当你明确需要访问外围实例的非 final 字段、且已确保该实例完全初始化并线程安全时，才考虑非静态内部类。
立即学习“Java免费学习笔记（深入）”；
- 禁止在构造器中创建并启动非静态内部类实例（含匿名 Runnable/Thread）
- 如需注册监听器或回调，改用两阶段初始化：先完成构造，再调用独立的
init()或start()方法 - 若内部类必须持有外部引用，确保外围类字段尽量用 final 修饰，并配合 volatile 或锁保证可见性
用 ThreadLocal 或不可变对象替代隐式共享
当内部类需要“感知”外围上下文，但又不想引入锁竞争或状态泄露，可转向更安全的线程封闭策略：
- 用
ThreadLocal<T>为每个线程提供独立副本，避免跨线程共享同一实例 - 将需传递的数据封装为不可变对象（final 字段 + 无 setter），通过构造参数传给内部类，杜绝后续修改带来的并发风险
- 对可变集合等资源做防御性拷贝（如
Collections.unmodifiableList(list)），防止内部类意外修改原始状态
