将所有方法声明为static能否节省内存？该用法适用场景及性能如何？

适用该静态方法声明方式的场景 #

• 核心逻辑复用场景：和你提到的Integer.toString()的实现思路一致，当某段逻辑既需要给当前类的实例方法调用，也需要给外部/类内部其他场景直接传入实例调用时，把无状态的核心逻辑抽为私有静态方法，可以避免代码重复，同时对外只暴露符合面向对象设计的实例方法入口。
• 方法逻辑完全无依赖：当方法执行逻辑只依赖传入的参数，不需要访问当前类的非静态成员变量、非静态方法时，适合声明为静态方法，实现逻辑和实例解绑。
• 无实例调用需求：部分不需要创建类实例就能调用的工具逻辑、工厂生成逻辑，也适合用静态方法实现。

内存与性能表现 #

• 内存方面：该写法能节省的内存空间几乎可以忽略不计。 Java的实例方法本身存放在方法区，所有类实例共享同一份方法字节码，不会因为实例数量增加而重复占用内存。静态方法和实例方法的内存占用差异仅在于调用时隐含传递的this引用，单次调用只会少占几个字节的栈空间，完全感知不到差异。
• 性能方面：静态方法属于静态绑定，调用时不需要做虚方法分派，理论上比普通实例方法调用速度稍快，但JVM的JIT编译器会对高频调用的实例方法做去虚化、内联等优化，实际运行时两者的性能差异可以忽略，完全不需要为了性能特意把实例方法改成静态。

全类方法声明为static节省内存的合理性 #

这种做法完全不合理，也不具备实际应用价值：

• 严重违背面向对象设计原则：静态方法无法被重写，不支持多态特性，所有方法都声明为静态等于完全放弃了面向对象的扩展性、可维护性优势，后续需求迭代的成本会极高。
• 内存收益极低：如前所述，这种做法能节省的内存微乎其微，和代码可维护性的损失比起来完全不值当。
• 额外风险更高：如果静态方法中使用了静态成员变量，还会额外引入线程安全问题，提升bug出现的概率。

内容的提问来源于stack exchange，提问作者Christoph S.