在传统的web项目中，防止重复提交，通常做法是：后端生成一个唯一的提交令牌（uuid），并存储在服务端。页面提交请求携带这个提交令牌，后端验证并在第一次验证后删除该令牌，保证提交请求的唯一性。

上述的思路其实没有问题的，但是需要前后端都稍加改动，如果在业务开发完在加这个的话，改动量未免有些大了，本节的实现方案无需前端配合，纯后端处理。

思路

1、自定义注解 @NoRepeatSubmit 标记所有Controller中的提交请求

2、通过AOP 对所有标记了 @NoRepeatSubmit 的方法拦截

3、在业务方法执行前，获取当前用户的 token（或者JSessionId）+ 当前请求地址，作为一个唯一 KEY，去获取 Redis 分布式锁（如果此时并发获取，只有一个线程会成功获取锁）

4、业务方法执行后，释放锁

这里只贴出 AOP 类和测试类

多线程测试

测试代码如下，模拟十个请求并发同时提交

成功防止重复提交，控制台日志如下，可以看到十个线程的启动时间几乎同时发起，只有一个请求提交成功了

在传统的web项目中，防止重复提交，通常做法是：后端生成一个唯一的提交令牌（uuid），并存储在服务端。页面提交请求携带这个提交令牌，后端验证并在第一次验证后删除该令牌，保证提交请求的唯一性。

上述的思路其实没有问题的，但是需要前后端都稍加改动，如果在业务开发完在加这个的话，改动量未免有些大了，本节的实现方案无需前端配合，纯后端处理。

思路

1、自定义注解 @NoRepeatSubmit 标记所有Controller中的提交请求

2、通过AOP 对所有标记了 @NoRepeatSubmit 的方法拦截

3、在业务方法执行前，获取当前用户的 token（或者JSessionId）+ 当前请求地址，作为一个唯一 KEY，去获取 Redis 分布式锁（如果此时并发获取，只有一个线程会成功获取锁）

4、业务方法执行后，释放锁

这里只贴出 AOP 类和测试类

多线程测试

测试代码如下，模拟十个请求并发同时提交

成功防止重复提交，控制台日志如下，可以看到十个线程的启动时间几乎同时发起，只有一个请求提交成功了