咨询一个关于锁的业务问题

用不用不是得看正确性吗，当然除了传统意义上的分布式锁之外也有别的方案，比如乐观并发控制

吃不了多少性能吧，而且 web 中分布式锁都是对特定资源加锁，除非是秒杀这种特定场景否则对并发性影响几乎可以忽略不计，而且靠谱一点的分布式锁方案网络正常情况下延时都应该低于 2ms ，这对接口响应时间来说的影响也不大吧，主要就是加锁直观简单且靠谱，你看直接套用系统的多线程编程都很难了，其实用其它方案其实更复杂的，想要设计完备其实就更难了

没有什么绝对的事情， 建议多看看架构设计的书。
软件架构设计没有银弹，只有取舍。

当你要访问共享资源，又可能会发生并发修改问题的时候，没办法不用锁。如果不会造成并发修改冲突，无锁编程肯定性能高。

比如使用旁路缓存模式，从数据库加载 1 万条数据列表大概 10MB 到 redis ，这时候并发请求读取，A 线程读取数据库 1 万条，B 线程也来读取发现 Redis 数据不存在也去请求数据库，这时候 B 读取数据库发现有人更新了读取到了 1 万零 1 条，然后 B 线程执行快先完成将数据写入 Redis ，A 线程此时慢了一步继续写入 Redis ，那最新的一条数据就被覆盖了，这时候缓存和数据库就不一致。

当然也可以用队列来处理这种情形。

信号量一般用在对资源的数量要求极度精准的情况，比如限流最高就要求同一单位时间 1000 人访问，那使用信号量就会特别精准，而且还能应对流量突刺，同时不会产生临界区问题，你使用其他的限流算法就比较难做到。

所以，如果你现在还没有使用锁和信号量，那一般是以下三个情况：

1. 你的业务场景确实暂时不需要，不必强加
2. 你还没有在线上遇到过由并发读写产生的 bug ，所以还没发现
3. 因为缺少并发处理经验，所以暂时缺少这部分的意识，需要补充

看情况，大部分的表单提交请求冲突覆盖都没问题，没必要上锁，客户端做好 button disabled 尽量避免重复发送就行，交易、订单、等需要严格递增插入的场景必须上锁，避免脏状态落库，java 可以考虑用这个：[redisson]( https://github.com/redisson/redisson)，大部分需求都能满足了。

@codehz 同意。用不用是看需要看需求，掌握好技能根据实际情况决定，不是看博客下爆论。

分布式锁、分布式读写锁、乐观锁这三个用的多。没获取到锁或者条件不满足，让调用方自己重试

搞 web 看下分布式锁的原理 以及 mysql 锁的原理,jdk 自带的锁都是单机的,用的很少

看场景，看业务。