求大神解答一下一个小白程序员的疑惑

private static final Set<String> LOCK_SET = new CopyOnWriteArraySet<>();  public String execute(){ ...     synchronized (this) {         if (LOCK_SET.contains(uuid)) {             return "failed";         }         LOCK_SET.add(uuid);     } ... } 

• 資深大佬 : IGJacklove

  感觉 redis 不算大材吧…

• 主 資深大佬 : Joezeo

  @IGJacklove 主要我是感觉这个没有必要用 redis..

• 資深大佬 : kop1989

  我没太读懂。
  redis 不是一个缓存技术么，只是作用于存储。

  对于接口黑名单而言（二次提交也是黑名单，只不过是持续时间很短），不管用什么技术存储黑名单，锁是一定要存在的吧，所以不管用不用 redis，读取黑名单这步骤依然是要队列执行的。

• 資深大佬 : kop1989

  所以你们的争论其实就是 new 对象和用 redis 来存储黑名单的区别？

• 資深大佬 : Immortal

  早起还没有前后端分离的时候 后端会在 form 里渲染一个 key 存在这个 key 并且和服务端一致才让提交
  现在前后端分离了 前端可以同样按这个思路 客户端自己维护这个 key
  这类解决方案 google 下很多的 用 redis 啥的有点夸张了

• 主 資深大佬 : Joezeo

  @kop1989 emmm 差不多就是这个意思，我们争论的点就是在这个情况下有没有必要使用 redis 来进行存储

• 主 資深大佬 : Joezeo

  @Immortal 好的，感谢(我也是觉得这个用 redis 有点夸张了)

• 資深大佬 : kop1989

  @Joezeo #6 如果我理解的没错的话，那优缺点就很明显了。
  直接 new 一个对象集合来存储是不可靠的，有可能被 web 容器的垃圾清理释放掉。
  redis 相对安全，但 redis 的效率比直接 add 进集合再 remove 肯定是要慢很多。

  但还是要强调下，这个话题和锁不锁无关，这种场景肯定是要有锁的，只不过 redis 是单线程，你不需要去操作锁而已。所以你同事说的啥“当其他用户的请求来时会被锁住等待”这个对 redis 也一样适用。

• 資深大佬 : IGJacklove

  @Joezeo 我感觉你锁接口比用 Redis 重的多，你的问题是单用户的重复提交，你的解决方案是锁全部人的提交。感觉你的问题不是更大吗？假如有一百个人的 200 个请求过来，你要做的就是拦住一百个人的后一百次重复提交，你的解决方案是锁了所有人的提交，这不是明显有问题吗？要是一百个人的一百次请求你根本不需要锁啊

• 資深大佬 : hahasong

  CSRF token 不香吗，提交一次就失效，不刷新页面再提交肯定失败

• 資深大佬 : 013231

  如果服務進程不止一個，你的本地鎖要如何解決兩次請求落在兩個不同進程的問題？

• 資深大佬 : 672795574

  11 说的才是要解决的问题，你本地锁得保证这个用户的请求落到同一台机器上

• 資深大佬 : wysnylc

  sync 在分布式下无用

• 資深大佬 : ZSeptember

  首先看是不是单服务器部署，再看用户量级以及请求量。
  单服务器部署，用户量级少，请求量少，可以放内存。

• 資深大佬 : opengps

  推荐保留 redis，因为他可以集群内共享，扩展集群时候不用你额外改动代码

• 資深大佬 : byzf

  目测你这个 add 再 remove 一下, LOCK_SET 大了受不了.

  redis 就是用来做这个的, 不算大材小用.

• 資深大佬 : Jooooooooo

  这

  分布式的锁和内存里单机的锁没有可比性