工具类需用private构造方法防止误实例化，正确做法是声明final类、private构造器内抛异常、不实现Serializable。
为什么工具类需要 private 构造方法
Java 中的工具类（如
、
）通常只提供静态方法，不承担状态管理。如果允许外部调用默认构造方法，就可能被误实例化——哪怕没人用，编译器也默认生成一个 public 的无参构造器，这违背了“纯工具”的设计意图。加
构造方法，能从编译期就堵死这个口子。
编译器不会自动添加构造方法，一旦你显式声明了任意构造方法（包括
），就不会再生成默认的 public 构造器
即使类里只有静态成员和静态方法，没有
构造器，JVM 仍允许
（只要没显式禁止）
IDE（如 IntelliJ）会警告 “Utility class may be refactored to enum or final class with private constructor”——这是在提醒你补上防护
怎么写才真正不可实例化
光写
不够，还得防住反射和反序列化这类绕过访问控制的手段：
反射可以调用
强行访问 private 构造器，所以构造方法体内要加运行时检查：
反序列化（如
）会绕过构造器直接创建对象，需定义
或更稳妥地：让类实现
并抛出异常（但工具类一般不该实现
）
更彻底的做法是把类声明为
（防止子类重写或绕过）
示例：
}
常见误操作：空构造体 + 忘记 final
很多人只写了个空的
构造方法，但忽略两个关键点：
类没加
：别人可以
，然后在子类里调用
实例化父类（虽然父类构造器是 private，但子类内部合法）
构造方法体为空：反射仍可成功创建实例（只是对象字段全为 null），起不到实质防护作用
在模块化环境（Java 9+）中，若未导出包，即使有
构造器，跨模块反射也可能失败——但这属于环境限制，不是代码层面的防御
所以正确姿势是：
加
修饰类
构造方法体必须抛异常（不能空）
不实现
（除非真有反序列化需求）
替代方案：用枚举代替工具类？
枚举天生不可继承、不可反射实例化（
的构造器被 JVM 特殊保护），且强制单例。写成：
}
但要注意：
枚举类隐含实现了
和
，如果工具类被用于敏感上下文（如安全框架），多出的接口可能引发意外交互
部分静态分析工具（如 SonarQube）会把枚举里的静态方法标为“非典型用法”，产生噪音
枚举实例名（这里是
后的空枚举常量）虽不可见，但字节码里仍存在一个
字段——对极简主义者来说，这仍是“多余的状态”
真正干净的工具类，还是
最直白可控。反射防护靠的是“让它跑起来就错”，而不是“让它根本进不来”。
StringUtilsObjectsprivateprivate Utils() {}privatenew Utils()private Utils() {}setAccessible(true)if (this != null) throw new UnsupportedOperationException();ObjectInputStream.readObject()private Object readResolve() { return INSTANCE; }SerializableSerializablefinalpublic final class StringUtils {
private StringUtils() {
if (StringUtils.class.getClassLoader() != null) {
throw new UnsupportedOperationException("Cannot instantiate utility class");
}
}
public static boolean isBlank(String str) { ... }
privatefinalextends StringUtilssuper()privatefinalprivateSerializableEnumpublic enum StringUtils {
;
public static boolean isBlank(String str) { ... }
SerializableComparable;INSTANCEfinal + private 抛异常构造器