私有构造方法通过编译期拦截与运行时兜底双重防护阻止实例化：编译期报错“cannot resolve constructor”，运行时抛unsupportedoperationexception异常；必须配合final类声明、private修饰符及异常抛出三要素，缺一不可。
私有构造方法通过编译期拦截 + 运行时兜底，从语法和语义两个层面阻止外部实例化。
编译期直接报错，切断最常见误用
Java 编译器默认为无显式构造器的类生成一个 public 无参构造器。一旦开放，任何地方都能写 new StringUtils()，编译通过、运行正常，但完全违背工具类“只提供静态方法”的设计本意。声明 private Utils() {} 后，编译器不再生成默认构造器，且外部调用 new 会立即报错：“Cannot resolve constructor” 或 “Illegal constructor access”。
必须配合 final 类声明和异常抛出
光写 private 构造器还不够，三个要素缺一不可：
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 类必须加 final：防止子类继承后在内部调用 super() 实例化父类
- 构造器必须是 private（不能省略或写成包私有/protected）
- 构造器体中必须 throw 异常，如 throw new UnsupportedOperationException("Utility class cannot be instantiated")；空构造体无法阻止反射成功创建对象（字段全为 null），但异常能让反射调用在运行时失败并暴露问题
它不防反射，但也不该指望它防反射
反射通过 Constructor.setAccessible(true) 确实能绕过 private 访问控制——这是 JVM 层级能力，不是漏洞，而是设计使然。Collections、Objects 等 JDK 工具类都采用相同模式，目的不是技术封杀，而是清晰表达“你不该这么干”的契约。真正有效的防护是设计源头：工具类不持状态、所有方法 static、不实现 Serializable、不支持反序列化。若真有敏感逻辑，应移到受控的 Service 类中，而非依赖构造器封锁。
IDE 和静态检查是重要补充
现代 IDE（如 IntelliJ）会在检测到只有静态成员的类缺少 private 构造器时，主动提示 “Utility class may be refactored to final class with private constructor”。团队还可接入 SpotBugs 等工具，在 CI 阶段扫描未加 private 构造器的工具类，把防护前移到开发流程中。这比靠人肉 Code Review 更可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
