小明学架构师的第六课：享元模式：能共享的绝不新建

一个字概括享元：省。 两个字：复用。 三个字：对象池。 结构型模式的收官之作，也是最"功利"的一个模式——不讲究优雅，只讲究效率。一、一句话理解享元模式一句话生活类比享元 Flyweight相同内部状态的对象只创建一个，放在池里共享；不同的部分由外部传入共享单车：车是固定的，谁骑、骑到哪由你决定💡享元的核心思想：把对象的状态拆成两半：内部状态：不变的、可共享的部分（如字体、颜色、类型）→ 放在享元对象里外部状态：变化的、不可共享的部分（如坐标、时间、用户ID）→ 由外部传入一句话：能共享的都共享，不能共享的外部传。二、小明遇到了性能危机2.1 系统要崩了小明的公司做了一个在线文档协作平台。用户在文档里打字，每个字符都要渲染。第一版代码是这样的：class Character {private char content; // 字符内容private String font; // 字体private int size; // 字号private String color; // 颜色private int row; // 行号private int col; // 列号// 每个字符都 new 一个完整对象public Character(char content, String font,int size, String color,int row, int col) {this.content = content;this.font = font;this.size = size;this.color = color;this.row = row;this.col = col;}}一篇1万字的文档，每个字符一个对象 =1万个对象。100个用户同时在线 =100万个对象。💥后果：JVM堆内存爆了，GC疯狂回收，系统卡成PPT。 运维报警：GC耗时超过50%，CPU占用90%+，但真正干活的业务逻辑不到10%。小明分析了一下，发现了一个关键事实：一篇文档里，字体、字号、颜色通常只有几种组合。比如全文都是"宋体12号黑色"，只有字符内容和位置不同。也就是说：1万个字符对象里，99%的状态是重复的