Properties操作配置文件与键值对管理方法

Java中Properties配置文件管理看似简单，实则暗藏乱码、类型不安全、格式丢失和线程不安全四大陷阱：用load(InputStream)读UTF-8中文必乱码，必须改用指定UTF-8编码的load(Reader)；应始终使用setProperty()而非put()以避免ClassCastException；store()会无情覆盖原文件并抹除所有注释与格式，无法满足运维友好需求；而多线程下load-modify-store流程缺乏原子性，极易引发配置覆盖丢失——这些“小细节”正是线上故障的高频源头，尤其在共享配置场景下尤为危险。

Properties.load() 读取配置文件时中文乱码怎么办

Java 的 Properties 默认用 ISO-8859-1 解码，遇到 UTF-8 编码的中文配置文件，load(InputStream) 会把中文变成问号或方块。这不是文件写错了，是读法不对。

• 用 load(Reader) 替代 load(InputStream)，显式指定编码：

  try (Reader reader = Files.newBufferedReader(Paths.get("config.properties"), StandardCharsets.UTF_8)) {
      props.load(reader);
  }

• 别用 new FileReader("config.properties") —— 它依赖系统默认编码，Windows 和 Linux 表现不一致
• 如果必须用 load(InputStream)（比如老项目兼容），得自己转码：先用 UTF-8 读字节流，再按 ISO-8859-1 转成字符串传给 load()，但容易出错，不推荐

setProperty() 和 put() 都能存值，该选哪个

setProperty(String, String) 是 Properties 的专用方法，put(Object, Object) 继承自 Hashtable。表面都能塞键值，但行为差异明显。

• setProperty() 会自动对 key 和 value 做 String.valueOf() 转换，并且在保存时对特殊字符（如 =、:、空格）做转义；put() 不处理，直接存 Object 引用，后续 store() 可能抛 ClassCastException
• 所有 key 和 value 必须是 String 类型，这是 Properties 的契约。用 put(123, true) 看似能过编译，但调用 store() 时会失败
• 实际开发中只用 setProperty()，避免类型混淆和保存异常

store() 写入文件后，注释和原有格式全没了

Properties.store() 是“覆盖写入”，它只保证键值对正确，不保留原文件的空行、注释、键顺序或缩进。这不是 bug，是设计如此。

• 如果需要保留格式（比如运维要手改配置），别用 store()，改用 storeToXML() 或自行解析/拼接文本
• store() 第二个参数是 header 注释，只写在文件最开头，且自动加 #，不能插在中间
• 想追加新配置？Properties 没有原生 append 模式，得先 load() 全量，再 setProperty()，最后 store() 全量覆盖

Properties 在多线程环境下安全吗

不安全。虽然 Properties 继承自 Hashtable（方法加了 synchronized），但它的典型使用流程——load() → 修改 → store()——是三个独立操作，中间没锁保护。

• 两个线程同时 load() 同一个文件，各自修改后 store()，后写入的会完全覆盖前者的改动
• 如果只是读多写少，可用 Collections.synchronizedMap(new Properties()) 包一层，但无法解决 load/store 的原子性问题
• 真正可靠的方案是：写操作加外部锁（比如 synchronized(fileLock)），或改用 java.util.prefs.Preferences、Spring 的 @ConfigurationProperties 等更现代的配置管理方式

今天关于《Properties操作配置文件与键值对管理方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！