单例模式是基于OOP思想的创建型设计模式，非OOP三大特征；它通过私有构造器、静态变量与方法实现封装、类级抽象和对象唯一性，解决配置管理器、日志器等不可复制资源的全局共享问题，但因隐式全局状态、难继承、静态绑定等缺陷而削弱OOP弹性，现代开发倾向依赖注入替代。
Java单例模式本身不是OOP的三大基本特征（封装、继承、多态），而是基于OOP思想落地的一种设计模式，归类于创建型设计模式。
单例是面向对象思想的实践产物
它依赖并强化了OOP的核心机制：
- 用私有构造器实现封装——阻止外部随意 new 实例
- 靠静态成员变量 + 静态方法控制实例生命周期——体现类级行为抽象
- 通过自行创建、自行管理、全局唯一访问，把“一个类 = 一个对象”的语义显式建模出来
单例解决的是OOP中“对象唯一性”这一现实约束
面向对象强调万物皆对象，但现实中有些资源天然不可复制：
- 系统配置管理器：读一次配置，全系统共享，不该反复加载
- 日志写入器：多个模块写日志，必须串行或统一调度，避免文件冲突
- ID生成器：数据库主键、订单号等必须全局递增不重复
- 线程池/连接池：复用昂贵资源，而非每次新建销毁
单例背后的三个硬性设计原则
它不是随便加个 static 就叫单例，必须同时满足：
立即学习“Java免费学习笔记（深入）”；
- 唯一性：JVM中该类有且仅有一个实例（含反序列化、反射场景）
- 自控性：实例由类自身创建，不依赖外部工厂或容器
- 可及性：提供稳定、线程安全的全局访问入口（如 getInstance()）
为什么说它“对OOP不友好”？这是个重要提醒
单例在实际工程中容易违背OOP本意：
- 隐式全局状态 → 破坏封装，导致单元测试难、耦合高
- 无法继承或动态替换 → 削弱多态能力，不利于扩展和 Mock
- 静态绑定 → 违反“依赖倒置”，上层模块直依赖具体类
- 有参构造受限 → 难以注入配置或依赖，灵活性差
所以现代开发更倾向用依赖注入（如 Spring 的 @Scope("singleton")）替代手写单例，既保唯一性，又不牺牲OOP弹性。
基本上就这些。
