System类不是单例模式的实现，而是纯静态工具类：所有成员和方法均为static，构造器私有但不用于实例化，无getInstance()等实例获取方式，仅封装系统级操作，不维护自身实例或可变状态。
Java 中的 System 类**并不是单例模式的实现**，而是一个**纯静态工具类**——它没有提供任何获取实例的方法（如 getInstance()），也不维护自身实例，所有成员（out、in、err）和方法（currentTimeMillis()、exit()、gc() 等）均为 static，且构造器被私有化但从未被用于创建对象。它的设计目标是封装底层系统级操作，而非管理唯一对象实例。
System 类本质是静态类，不是单例
它完全符合“静态类”的典型特征：
- 所有字段和方法都用
static修饰，无需实例即可调用 - 构造器为
private System() {}，但从未被用于初始化实例 - 没有
getInstance()或类似入口，无法获得或持有其对象引用 - 不承载可变状态（
out、in、err是可重新赋值的静态引用，但System自身不封装业务状态）
单例模式与 System 类的关键区别
真正体现单例思想的是像 Runtime 这样的类：Runtime.getRuntime() 返回当前 JVM 的唯一运行时实例，该实例由 JVM 控制、可扩展（不同 JVM 可返回不同子类实现），且能维护内部状态（如内存使用、进程管理）。而 System 不满足单例三要素：
- ❌ 不自行创建唯一实例（它自己不 new 出任何对象）
- ❌ 不对外提供该实例的访问入口（没有“自己的实例”可提供）
- ❌ 不封装需要统一管理的状态逻辑（仅转发底层 native 调用）
为什么 System 用静态而非单例？
这种设计服务于它的定位：
立即学习“Java免费学习笔记（深入）”；
- 极致轻量：无对象创建开销，调用直接绑定到字节码层面，性能最优
-
无状态封装：它只是标准输入/输出/错误流的“门面”，实际状态由
PrintStream、InputStream等对象承担 -
不可继承不可扩展：所有方法都是
final static，避免被覆写，保证行为确定性与安全性 -
全局契约性：JVM 规范强制要求
System行为一致，不允许用户干预其实例生命周期
对比参考：Runtime 才是典型单例
作为对照，Runtime 明确体现单例价值：
- 每个 JVM 进程中仅存在一个
Runtime实例 - 通过
getRuntime()获取，且该方法可被子类重写（虽实际极少这么做） - 内部维护资源（如线程池、内存监控），需统一调度与状态同步
- 支持
addShutdownHook()等需实例上下文的操作
