模块化本身不直接提升多线程变量隔离性，但Java 9+模块系统（JPMS）协同ThreadLocal、类加载器隔离等机制，可从架构层与运行层双重加固线程安全边界：通过module-info.java限定访问、ThreadLocal实现模块内线程自治、模块类加载器保障资源硬隔离，并需规避opens滥用、公共ThreadLocal导出及全局属性设置等反模式。
模块化本身不直接提升多线程下的变量隔离性，但Java 9+的模块系统（JPMS）与ThreadLocal、类加载器隔离等机制协同使用时，能从**架构层+运行层**双重加固线程安全边界。关键在于：模块化控制“谁能访问”，而线程局部存储控制“谁拥有副本”。二者结合，可杜绝跨模块非法共享、避免线程间意外污染。
用module-info.java强制限定变量可见范围
模块声明能阻止外部模块直接访问内部状态变量，从源头减少误用风险：
- 未导出的包内定义的静态变量、单例对象或配置类，即使被反射尝试访问，也会在运行时抛出
IllegalAccessException（强封装生效） - 例如：
com.example.auth模块只导出com.example.auth.api包，其内部TokenContext类中维护的private static Map<String, User>无法被com.example.report模块读取或修改 - 这比单纯靠“约定不访问”更可靠——编译期和启动期即校验，不是靠开发自觉
配合ThreadLocal实现模块内线程级数据自治
模块内需跨方法传递上下文（如用户ID、租户标识）时，应避免用静态变量，改用ThreadLocal并绑定模块生命周期：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 在模块初始化阶段（如
ServiceLoader加载时）创建ThreadLocal实例，并设为private static final，确保每个模块独占一份线程副本 - 务必搭配
remove()清理：尤其在线程池场景下，不清理会导致前一个请求的上下文残留到后续请求中 - 示例：模块
com.example.tenant中定义static final ThreadLocal<String> CURRENT_TENANT = ThreadLocal.withInitial(() -> "default");，其他模块无法引用该变量，也无法篡改其值
利用模块类加载器实现运行时资源硬隔离
不同模块可由独立的ModuleLayer和自定义ClassLoader加载，使同名类在不同模块中互不可见：
立即学习“Java免费学习笔记（深入）”；
- 例如，
com.example.logging与com.example.network各自加载自己的ConfigHolder类，即便类名相同、字段相同，JVM也视作完全不同的类型 - 这种隔离让“全局静态变量”真正变成“模块级静态变量”，天然规避了跨模块线程竞争
- 配合安全管理器（SecurityManager），还可限制某模块的
ThreadLocal只能绑定特定类型的值，进一步收窄攻击面
避免常见反模式
以下做法会削弱模块化对线程隔离的增益：
- 在
module-info.java中过度使用opens或open module——这会绕过强封装，使反射可穿透模块边界 - 把
ThreadLocal变量声明在公共工具类（如Utils.java）中并导出，导致多个模块共用同一份ThreadLocal实例 - 依赖
System.setProperty()或java.util.Properties全局设置参数——这些是JVM级共享，模块化无法约束
