Jakarta EE中自定义ConstraintValidator内部字段的线程安全性问题

我编写了如下自定义ConstraintValidator：

public class FileNamePatternValidator implements ConstraintValidator<FilenamePattern, FileUpload> {

   String regex;

   @Override
   public void initialize(FilenamePattern constraintAnnotation) {
      regex = constraintAnnotation.regex();
   }

   @Override
   public boolean isValid(FileUpload fileUpload, ConstraintValidatorContext context) {

      if (fileUpload == null) {
         return true;
      }

      // 检查fileUpload的文件名是否符合规则

      return true;
   }
}

我将@FilenamePattern注解应用到REST接口方法的参数上，代码如下：

@POST
@Consumes(MediaType.MULTIPART_FORM_DATA)
@Path("{xy}")
public Response saveXY(
      @PathParam("xy")
      String xy,
      @RestForm("txtFile")
      @FilenamePattern(regex = "^[a-zA-Z_\\.]+\\.txt$")
      FileUpload txtFile
) {
   // 处理文件逻辑
   return Response.ok().build();
}

该接口会被并行调用，我想咨询：是否需要担心此ConstraintValidator的线程安全性？若Jakarta EE容器将ConstraintValidator作为单例处理，那么String regex字段属于共享资源，是否需要将其存储为ThreadLocal？

不需要担心线程安全问题，也完全没必要用ThreadLocal，原因如下：

• ConstraintValidator的生命周期特性：Jakarta EE容器通常会将每个ConstraintValidator实现类实例化为单例，但initialize方法只会在实例创建后被调用一次，之后不会再执行。也就是说你的regex字段只会被赋值一次，后续所有请求的isValid调用都只会读取这个值，不会对它进行修改。
• String的不可变性：String是Java中的不可变类型，一旦赋值就无法修改内容。多个线程同时读取同一个不可变对象的属性，本身就是线程安全的，不存在并发修改的风险。
• ThreadLocal的适用场景：ThreadLocal是用来存储线程私有、且可能会被动态修改的状态数据。而你的regex是固定的配置值，初始化后不会变化，用ThreadLocal反而会额外消耗内存，完全没必要。

如果后续你的Validator需要在isValid方法中修改某个状态字段，那才需要考虑线程安全（比如将状态改为方法内的局部变量，或者使用ThreadLocal），但当前代码的写法完全没有问题。

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