Jersey+DeclarativeLinking+@NotNull的HTTP POST请求内存耗尽循环问题

我之前在做Jersey接口开发时也踩过几乎一模一样的坑，结合你的代码来看，这个内存循环问题大概率是DeclarativeLinking与Bean Validation（也就是你用的@NotNull）的交互冲突引发的，尤其是当框架默认的异常处理逻辑和DeclarativeLinking的自动机制撞在一起时，会触发无限的异常抛出-处理循环，最终把内存榨干。

问题根源分析 #

• 当@NotNull注解检测到参数为空时，会抛出ValidationException，而Jersey的默认异常处理器在处理这个异常时，可能会触发DeclarativeLinking的内部逻辑（比如自动生成错误相关的链接）。
• 这个生成链接的过程又会再次触发参数校验或者资源扫描，进而再次抛出异常，形成死循环，错误日志会反复出现，内存占用持续飙升。

具体解决方案 #

下面是我当时解决这个问题的几个步骤，亲测有效：

1. 自定义ValidationException异常处理器

写一个ExceptionMapper来接管Bean Validation的异常处理，避免框架默认处理触发循环：

@Provider
public class ValidationExceptionHandler implements ExceptionMapper<ValidationException> {
    @Override
    public Response toResponse(ValidationException ex) {
        // 返回明确的400错误和简单提示，避免复杂的框架默认处理
        return Response.status(Response.Status.BAD_REQUEST)
                .entity("请求参数不合法：" + ex.getMessage())
                .type(MediaType.TEXT_PLAIN)
                .build();
    }
}

记得把这个类注册到你的Jersey配置中（比如在ResourceConfig的register方法里添加）。

2. 禁用DeclarativeLinking的自动错误链接生成

在Jersey的配置类中添加如下属性，阻止DeclarativeLinking在异常时生成链接：

public class JerseyConfig extends ResourceConfig {
    public JerseyConfig() {
        // 注册你的资源类和异常处理器
        register(Auth.class);
        register(ValidationExceptionHandler.class);
        
        // 禁用DeclarativeLinking的相对路径链接生成，避免触发循环
        property(ServerProperties.LINKING_RELATIVE_PATH, false);
    }
}

3. 检查版本兼容性

确保你的Jersey、DeclarativeLinking和Bean Validation（比如hibernate-validator）版本是兼容的：

• Jersey 2.3x+ 建议搭配 hibernate-validator 6.x
• 如果你用的是较老的Jersey版本，对应匹配的hibernate-validator版本也要下调（比如Jersey 2.2x对应hibernate-validator 5.x）
  版本不匹配很容易触发各种奇怪的框架内部bug，包括这种循环问题。

4. 临时排查：手动替代@NotNull校验

如果上面的方法还没解决，可以先把@NotNull注解去掉，改用手动参数校验来验证问题根源：

public Response createLogin(
        @FormParam("username") final String username,
        @FormParam("password") final String password,
        @Context final UriInfo uriInfo,
        @Context final HttpHeaders httpHeaders
) {
    if (username == null || username.isBlank()) {
        return Response.status(Response.Status.BAD_REQUEST).entity("用户名不能为空").build();
    }
    if (password == null || password.isBlank()) {
        return Response.status(Response.Status.BAD_REQUEST).entity("密码不能为空").build();
    }
    // 后续业务逻辑
}

如果手动校验后没有出现内存循环，那就实锤是@NotNull和DeclarativeLinking的冲突问题，回到前面的方案调整即可。

总结 #

这种内存循环问题本质上是框架组件之间的交互bug，通过自定义异常处理切断循环链、调整DeclarativeLinking配置、确保版本兼容这几个步骤，基本都能解决。

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