享元模式通过共享内部状态、分离外部状态来减少对象数量，核心是对象池缓存享元实例，以内部状态为键实现复用；内部状态须不可变，外部状态由客户端动态传入，从而在不消灭对象的前提下显著降低内存开销。
享元模式通过对象池技术降低内存开销，关键在于“复用不变部分 + 延迟绑定可变部分”。它不靠消灭对象，而是让大量相似对象共享同一份内部状态，把变化的部分（外部状态）从对象体内剥离出来，由调用方动态传入。对象池是实现这一逻辑的基础设施——它缓存已创建的享元实例，避免重复构造，尤其在对象创建成本高或数量爆炸时效果显著。
对象池如何承载享元的核心逻辑
享元工厂内部维护一个池（通常是 ConcurrentHashMap 或 HashMap），以内部状态为键，具体享元实例为值。每次请求享元时，工厂先查池中是否存在对应内部状态的对象；存在则直接返回，不存在才新建并缓存。这个过程屏蔽了客户端对对象生命周期的感知，也天然实现了单例粒度的复用。
- 例如渲染10万个黑色圆形：所有圆的颜色、半径、边框样式（内部状态）相同，仅坐标（外部状态）不同。对象池里只需存1个“黑色圆形”享元实例，而非10万个完整对象
- 池的大小可控——不会无限增长，因为内部状态组合有限；而外部状态不占对象内存，只作为方法参数压栈，开销极小
- 池本身轻量，通常不涉及锁竞争（读多写少），用无锁结构即可高效支撑高并发获取
内部状态与外部状态的合理拆分是前提
对象池能否真正省内存，取决于是否准确识别哪些字段该放进享元对象（内部状态），哪些该交给调用方（外部状态）。拆分错误会导致两种问题：要么共享失效（内部状态包含可变字段），要么使用繁琐（外部状态传递过于复杂）。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 内部状态必须不可变：如字体名、颜色值、图标资源ID。一旦设好就不能改，否则破坏共享安全性
- 外部状态必须与业务上下文强相关：如用户ID、时间戳、屏幕坐标。这些信息天然无法共享，也不该固化在享元里
- 典型误判：把“是否已点击”这种业务状态当作内部状态，结果多个地方共用后行为错乱；正确做法是将其作为外部参数或由调用方单独管理
和常见对象池（如数据库连接池）的区别与联系
享元对象池和连接池、线程池表面相似，但目标不同：后者主要解决资源创建/销毁开销（I/O、系统调用），前者专注减少堆内存占用。不过二者常协同使用——比如一个图形系统中，享元池管理“图元模板”，而每个图元背后可能复用同一个连接池中的渲染上下文。
- 享元池管理的是轻量级、无状态（指内部状态）的逻辑对象；连接池管理的是重量级、有状态（连接会话）的资源句柄
- 享元对象可被任意线程安全复用（因内部状态不可变）；连接池中的连接通常需线程绑定或加锁隔离
- Java 中 String 常量池、Integer 缓存(-128~127)就是最朴素的享元池，无需显式工厂，JVM 自动维护
实际落地时的关键控制点
不是所有对象都适合进享元池。盲目套用反而增加复杂度。判断是否值得引入，需看三个硬指标：
- 对象实例数是否稳定大于 1000 且持续增长（如 UI 中每帧生成数百粒子）
- 对象中可共享字段的内存占比是否超过 60%（用 jmap 或 JFR 分析对象布局）
- 外部状态传递是否简洁——若每次调用需传 5 个以上参数，说明设计可能过重，应重新审视职责边界
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
