非静态内部类适合封装仅限外部类使用的逻辑，因其隐式持有外部类实例引用，可直接访问私有成员且对外不可见；需访问外部类实例成员时必须用它，否则应选静态内部类。
内部类为什么适合封装“仅限外部类使用”的逻辑
因为内部类天然持有对外部类实例的隐式引用（非静态内部类），能直接访问外部类的私有成员，同时对外不可见——这是最轻量、最符合封装意图的访问控制方式。它比把逻辑提成 public 工具类更安全，也比用 package-private 类更精准（后者仍可能被同包其他类误用）。
什么时候该用非静态内部类而不是静态内部类
当你需要内部逻辑频繁读写外部类的实例字段或调用其非静态方法时，必须用非静态内部类。静态内部类没有 this 引用，无法访问 private int count 或调用 updateStatus() 这类成员。
- 要访问外部类的
private字段或方法 → 选非静态内部类 - 只做纯数据封装或工具计算（如解析 JSON 片段），不依赖外部实例 → 静态内部类更轻量、无内存泄漏风险
- 若内部类对象生命周期可能长于外部类实例（比如被线程池缓存），必须用静态内部类 + 显式弱引用，否则会阻止外部类 GC
如何避免常见的内存泄漏和访问冲突
非静态内部类对象持有外部类强引用，这是双刃剑：方便访问，但也容易导致本该回收的外部类实例滞留。尤其在 Android 的 Activity 或 Swing 的 JFrame 场景下，泄漏后果明显。
- 异步任务中不要直接 new 非静态内部类并传给线程池，改用
static class LoaderTask extends AsyncTask<void void result></void>+ 通过构造参数传必要数据 - 监听器场景（如
addMouseListener(new MouseAdapter() { ... })）若写成非静态内部类且被长期持有，外部窗体无法释放；应优先用匿名内部类（作用域明确）或提取为静态内部类 - 外部类字段被内部类修改时，注意可见性：若字段是
int counter，多线程下需加synchronized或改用AtomicInteger，内部类不会自动带来线程安全
替代方案对比：内部类 vs 私有方法 vs package-private 类
内部类不是万能解。如果逻辑只是简单流程分段，用私有方法更清晰；如果逻辑本身有独立状态和行为（比如一个状态机、一次完整的数据转换流水线），内部类才真正体现价值。
- 逻辑只有输入输出、无状态 → 用
private void doValidation()更直白 - 逻辑需要维护中间状态（如解析器的当前偏移、临时缓冲区）、多次回调驱动 → 内部类让状态局部化，避免污染外部类字段
- 想跨多个外部类复用？说明它不该是“仅供外部类使用”，此时应拆为 package-private 类或模块内 utility 类，而非强行塞进某个内部类
关键在于：内部类的价值不在“语法存在”，而在它让一组高内聚的状态与行为彻底脱离公共接口视野——一旦你开始犹豫“这个类要不要加 Javadoc”或“要不要单元测试它”，大概率它已经越界了。
