根本原因是Properties.load(InputStream)强制使用ISO-8859-1解码，与UTF-8文件不匹配；应改用带UTF-8编码的Reader加载，或先读字节再显式解码为字符串后通过StringReader加载，确保并发安全且兼容\uXXXX转义。
旧版 JDK（如 8、11、17）中读取 .properties 文件时出现中文乱码，根本原因不是并发问题，而是 Properties.load(InputStream) 方法**强制使用 ISO-8859-1 解码字节流**，与 UTF-8 编码的配置文件不匹配。所谓“并发字节流转换”，实则是指在多线程环境下安全、一致地完成“字节 → UTF-8 字符串 → Properties 加载”这一链路，避免因共享流、编码误设或资源竞争导致乱码复现。
用线程安全的 Reader 加载替代 InputStream 路径
不要在多个线程中复用同一个 InputStream 或直接调用 load(InputStream)；应为每次加载构造独立的、带明确编码的 Reader：
- 从类路径读取：
InputStream is = clazz.getResourceAsStream("/config.properties");→ 包装为new InputStreamReader(is, StandardCharsets.UTF_8)→ 再传给props.load(Reader) - 从文件系统读取：
Files.newBufferedReader(Paths.get("config.properties"), StandardCharsets.UTF_8)，该方法本身线程安全且编码明确 - 若需缓存配置，确保
Properties实例本身被正确同步（如用ConcurrentHashMap存储不同配置集，或对单个Properties实例加读写锁）
统一预处理：先解码再 load，绕过所有隐式逻辑
在并发场景下，更推荐完全接管字节到属性的转换流程，消除任何 JVM 内部编码猜测：
- 用
Files.readAllBytes(path)或IOUtils.toByteArray(is)获取原始字节（无状态、可重复） - 用
new String(bytes, StandardCharsets.UTF_8)显式解码为字符串（UTF-8 无 BOM 前提下，结果确定） - 再用
props.load(new StringReader(decodedStr))加载——此路径不触碰任何 ISO-8859-1 硬编码分支 - 该方式天然支持并发：每个线程操作自己的字节数组和字符串，无共享状态风险
兼容混合格式：支持 \uXXXX 转义与明文共存
遗留项目常存在 name=张三 和 title=\u6b22\u8fce 混用的情况。上述 StringReader 方式仍可兼容，因为：
- UTF-8 解码后的字符串中，
\u6b22\u8fe1是普通 ASCII 字符序列，Properties.load(Reader)会照常调用其内部loadConvert方法还原 Unicode - 若需更高控制力（如统一日志记录、字段过滤），可复用 JDK 内部的
Properties#loadConvert逻辑，或使用java.util.Properties#unescape（JDK 11+ 可反射调用） - 避免在并发环境中修改
System.setProperty("file.encoding", ...)——它全局生效，会干扰其他线程的文件 I/O 或日志输出
配套工程实践：从源头杜绝编码歧义
并发只是放大了配置加载不稳定的后果，真正要解决的是“一次写对，处处读准”：
- IDE 中启用 Transparent native-to-ascii conversion（IntelliJ / IDEA：Settings → Editor → File Encodings），让中文自动保存为
\u5f20\u4e09形式，这样即使误走load(InputStream)路径也不会乱码 - 构建脚本（如 Maven Resources Plugin）强制声明
encoding=UTF-8，防止打包时编码被重写 - CI 流水线加入校验步骤：用
file --mime-encoding或 Java 工具类检测.properties文件是否为 UTF-8 无 BOM
