Java类成员位置创建LogMessage实例 是否需移至方法内部

没有绝对的对错，完全看LogMessage类本身的特性和实际使用场景，核心判断点拆成下面几类：

可以保留类层级实例化的情况 #

• 如果LogMessage是 无状态、线程安全的工具类：所有方法不依赖可变的实例字段，只靠传入参数完成逻辑，那么把它作为DoSomething的类成员是完全合理的。甚至可以直接把它升级为static final静态常量，复用单个实例，省去每次方法调用新建对象的GC开销。
  这种场景下可以顺手修下现有代码的小问题：
  • 给logMessage补上private修饰符和final关键字，符合封装要求，避免外部类意外改动这个对象引用
  • 确认完全无状态后直接提为静态常量，不需要每个DoSomething实例都单独new一个LogMessage
• 如果LogMessage需要持有和当前DoSomething实例同生命周期的状态：比如要维护和当前实例绑定的上下文、调用统计值之类的可变信息，那作为类成员创建的生命周期是完全匹配的，不需要挪到方法里。

必须把实例化移到方法内部的情况 #

• 如果LogMessage是 有状态、非线程安全的对象：它内部存了可变的实例字段，那现在这种类成员的写法在多线程环境下一定会出问题—— 多个线程同时调用DoSomething的方法时，会交叉修改同一个共享LogMessage实例的字段，导致逻辑错乱。这种场景下就必须把创建逻辑挪到实际使用的方法里，作为方法局部变量，每个线程自己拿独立的实例，互不干扰。
• 如果LogMessage的创建成本很高：比如实例化的时候要加载大配置、初始化连接、跑重计算，而DoSomething的方法并不是每次运行都会用到LogMessage，那提前在类层级建对象就是无意义的资源常驻占用，适合懒加载到实际使用的方法内，用到再建。

现有代码的其他规范问题 #

• 成员变量Flag的命名不符合Java编码习惯，普通成员变量一般用小驼峰，建议改成flag
• 现在的logMessage没有写访问修饰符，属于包级可见，封装性不足

内容的提问来源于stack exchange，提问作者jayachsi