在多线程或高频调用场景下，使用静态布尔变量会导致状态跨请求残留；正确做法是将标志改为局部变量，并通过参数或返回值传递状态，确保每次调用完全隔离。
在多线程或高频调用场景下，使用静态布尔变量会导致状态跨请求残留；正确做法是将标志改为局部变量，并通过参数或返回值传递状态，确保每次调用完全隔离。
在您提供的代码中，validPerson 和 invalidPerson 被声明为 static 字段，这意味着它们属于类级别而非实例级别——所有 Person 对象（甚至不同请求线程）共享同一份状态。当 getPersonInfo() 多次被调用时，前一次调用中 getAddressList() 修改的静态标志会持续保留，导致后续调用读取到过期的 true 值，违反了“每次请求应独立初始化”的基本设计原则。
✅ 正确解决方案：移除静态修饰符，改用方法级局部变量 + 显式状态传递
局部变量天然具备调用隔离性，每次进入 getPersonInfo() 都会重新初始化为 false。但注意：Java 中基本类型（如 boolean）按值传递，无法在被调用方法中修改调用方的局部变量。因此，不能简单将 validPerson 作为参数传入 getAddressList() 并期望其被“修改回”调用方——这只会改变副本。
更健壮、符合函数式思维的做法是：让 getAddressList() 返回一个封装结果与状态的对象，例如：
private static class AddressResult {
final List<String> addresses;
final boolean isValid;
final boolean isInvalid;
AddressResult(List<String> addresses, boolean isValid, boolean isInvalid) {
this.addresses = addresses;
this.isValid = isValid;
this.isInvalid = isInvalid;
}
}
private AddressResult getAddressList(String personData) {
List<String> addressData = new ArrayList<>();
boolean isValid = false;
boolean isInvalid = false;
if (personData == null) {
isInvalid = true;
} else {
isValid = true;
// ... process personData to populate addressData
addressData.add("123 Main St");
}
return new AddressResult(addressData, isValid, isInvalid);
}然后在 getPersonInfo() 中统一收集并聚合状态（若需支持多条 person 数据）：
public PersonDTO getPersonInfo(long personId) {
PersonDTO personDto = new PersonDTO();
List<PersonData> personList = fetchFromApi(personId); // 替换为实际 API 调用
// 初始化全局状态标志（默认 false）
boolean hasValid = false;
boolean hasInvalid = false;
List<AddressDTO> addressDetails = new ArrayList<>();
for (PersonData p : personList) {
AddressResult result = getAddressList(p.getData());
hasValid |= result.isValid;
hasInvalid |= result.isInvalid;
// 将 result.addresses 转为 AddressDTO 并添加到 addressDetails...
}
personDto.setIsValidPerson(hasValid);
personDto.setIsInvalidPerson(hasInvalid);
personDto.setAddressDetails(addressDetails);
return personDto;
}⚠️ 注意事项：
- 绝对避免在工具方法中依赖/修改静态状态，尤其在 Web 应用（如 Spring Controller）中，极易引发并发安全问题；
- 若
getAddressList()逻辑复杂且需复用，可进一步抽象为Function<string addressresult></string>或引入 Builder 模式； - 如需严格“互斥”语义（即
isValid和isInvalid不应同时为true），建议改用枚举（如PersonStatus.VALID / INVALID / UNKNOWN）提升可维护性。
总之，状态生命周期必须与业务上下文对齐——请求级状态就该存在于方法栈中，而非类的静态内存里。
