享元模式适用于共享带行为和固定配置的复合结构，而非基础数值或简单字符串；应分离内外状态、用工厂缓存组合键、行为方法接收外部参数。
直接说结论：享元模式不适用于“共享大量细粒度的数值变量”本身，而是用于共享**带有重复结构的轻量对象**——比如规格、样式、模型、字符属性等。单纯想共享 int、double、String 这类基础值或简单包装类，用享元是杀鸡用牛刀，反而增加开销。
明确什么不能享元：原始数值和简单字符串
Java 中的 int、long、boolean、Double.valueOf(123.45) 等已由 JVM 自动缓存或栈分配；String 字面量（如 "红色"、"L"）天然驻留字符串常量池。这些无需、也不该手动套享元工厂。强行包装成 Flyweight 对象，会引入对象头、引用、方法分发等额外内存与 CPU 开销，得不偿失。
真正该享元的，是“带行为+固定配置”的复合结构
享元生效的前提是：存在大量实例，它们内部有**多字段组合的稳定模板**，且这些字段共同决定某种可复用的行为逻辑。例如：
- 商品规格：color="红" + size="M" + material="棉" → 决定渲染样式、校验规则、运费策略
- 字体设置：family="微软雅黑" + weight="bold" + size=14 → 控制文本绘制、行高计算
- 游戏单位：type="弓箭手" + level=3 + skillSetId="ARCHER_BASIC" → 驱动AI行为、动画切换、伤害公式
这些不是单个数字，而是一组语义关联、不可拆分、只读的配置单元。享元共享的正是这个“单元”，不是其中某个字段值。
实战落地三步：分离、缓存、传参
第一步：严格剥离内外状态
把不变的模板字段（color/size/material）放进 Flyweight 类，声明为 final；把变化的数据（price、stock、x/y 坐标）彻底移出，由调用方持有。
第二步：用工厂按组合键查缓存
工厂内部用 ConcurrentHashMap
第三步：所有行为方法必须接收外部参数
比如 spec.render(productId, price, stock, x, y) —— 渲染逻辑在 spec 里，但价格、库存、坐标全由外部传入。绝不能让 spec 自己去查数据库或读成员变量。
警惕典型误用和边界
如果内部状态组合太多（比如 50 种颜色 × 50 种尺寸 × 50 种材质 = 12.5 万种），缓存本身就会吃掉几百 MB 内存。这时应：
- 降维：只共享材质+尺寸，颜色走外部传参
- 分层：一级享元管“大类”，二级管“子变体”
- 放弃享元：对象总数不到 1000 个时，别加这层抽象
享元不是给变量瘦身的工具，而是给“重复模板+行为逻辑”减负的机制。用对了，百万对象缩到百级；用错了，代码更重，内存更涨。
