update 大家会允许这样写吗？

不懂 JAVA
要么先开事务，要么条件里带上原来的值，保证绝对更新

select for update 行锁

楼主是想问，patch or update 吧，java 一般都是全字段更新（过滤 0 值）。
最好是 new 对象，set 对应值，而不是 select by Id ，然后 set 。
不过，无并发冲突，两种都没问题。
但是如果有并发，两种都有问题，都得加锁。

我想了一下，这样的问题除了给数据加上版本号貌似没什么特别好的处理办法了
我觉得还是得看业务，如果这个数据多人共享且并发两很高，那必须加锁
如果没这个需求应该无所谓

严格来说这样是有问题的。
比如你这个场景 1 逻辑是修改了 name,age 。如果另外的场景 2 是修改用户的 phone,并且 phone 修改在前，那么这个 phone 的修改会被场景 1 的旧 phone 覆盖。

以面向对象的思维来说一般都是这么写的。因为往往在实际业务中你把对象 select 出来除了赋值可能还会做很多业务逻辑和计算，完了就将整个对象 update 。如果在要求比较高的场景下，要解决并发问题就通过分布式锁来处理。

当然假如只是单纯更新数据的场景，这种写法并不好，因为可能只要更新一个字段却执行了两个 sql ，甚至把所有字段都更新了一遍，效率比较低，也存在你说的并发问题。所以简单的更新数据比较建议直接通过一句简单的 update 更新。

分场景呢，如果真的并发高那就加锁，要么乐观锁 version 字段，要么加分布式锁，按理说，用户不会天天修改自己的用户信息。

@dcsuibian 严格来说，不加锁的更新都有可能出你说的问题。加锁带来的问题是性能下降，和用户交互不友好。
但这个问题可以通过业务规则规避，只允许一个用户修改数据就啥问题都没了。

没啥 大影响 ..很多代码这么写的,虽然新开一个 userForUpdate 类会清淅一点
并不并发的,没区别,就算你只更新你的,并发你不加锁,开不开新类也控制不了
对于阿里/腾讯 这类优化过的 mysql,会自动过滤不需要更新的字段,对性能影响也不大

所以，问题出在 mapper 的 updatebyid 并不会像符合认知的 orm 行为那样，只修改自己变更过的字段。而是会 update 整个对象除了 ID 外所有的字段。

对不熟悉的人来说，这个还挺隐蔽的，但是想必已经是 java 生态内的常识了吧。

只更新需要更新的字段，全部更新没意义，重新 new 个对象更新

spring data jpa 中可以给实体加个 @Version 就能自动处理乐观缩，这种方式没有毛病，只有更新的一瞬间判断，感觉效率比行锁高。

那怎么写才正确呢 每个更新操作都考虑并发么

ef 使用 ChangeTracker 跟踪状态变化 只会更新变化的字段
java 的 orm 不清楚是否支持

除非需要事务， 不然我觉得这就是最好的选择。

局部变量这样写 没事吧

查询是不是多余了

如果你用 C# ef orm ，官方就是推荐这么写的，但是 ef 自带乐观锁支持和 patch 更新，改了什么字段就更新什么字段

这是 mysql 经典的丢失更新问题，举个相似例子，a 用户读取 user1 时 age=0 并修改 age=age+1=1 ，b 用户读取 user1 时 age=0 并修改 age=age+2=2 ，此时丢失了 a 用户的修改，中间其实更新了+1 ，所以处理时如果要满足场景你在读前就要加锁

某些场景下，绝对允许；
某些场景下，绝对不允许；
某些场景下，无所谓；
所以，你是哪个场景？

使用乐观锁更新的话，如果出现了并发有概率出现部分用户无法更新成功的情况，也就是数据库返回受影响行数为 0 ，这个时候需要提示用户修改失败，并要求重新刷新表单数据之后重新提交修改，并发量大的情况下，用户仍然有可能第二次提交也是失败的

使用锁的话，大概率是可以更新成功的，但可能遇到的问题有，并发量大时可能会等待，表现为用户提交表单等待的时间会长一点或者直接等待超时（这种情况下，有可能修改成功，也可能失败）。此外还有一个问题是，后提交的用户有可能会把之前提前的信息给覆盖掉（比如 #13 提到的问题）

如果按照锁升级策略来看的话，是否可以考虑如下策略
默认使用乐观锁，当出现冲突时，也就是数据库返回受影响行数为 0 时，进入重锁模式，重锁模式释放完毕之后，再做一个判断，如果当前没有使用资源的线程，则切换回乐观锁模式

用 MP 的 LambdaUpdateWrapper ，只更新指定字段

没并发问题吧, 这里只是用了一个比较蠢的办法去构造了 User u 而已.

为啥不按需更新？
```java
User u= new User();
u.setId(id);
u.setName(myname);
u.setAge(myAge);
userMapper.updateById(u);

```

就算是生成器生成的 mapper ，都有 updateByPrimaryKeySelective 吧
用一下又不麻烦，这样就是纯懒到家了。

我知道 python 的 flask 在
u.setName(myname);
u.setAge(myAge);
之后就可以直接 commit 了,
java 好像真没啥好办法, 想要性能好还要加锁就只能乐观锁了.

我感觉 v 站最多的就是 java 选手了，哈哈哈哈

@binge921 #42 对于业务代码，除了 java 没哪个语言能打的。这也侧面反映，写业务逻辑的人占据了大部分的。

和语言没关系，对于先 check 后操作的场景就是典型的竞态条件，一般要加锁。但也分场景，比如上面说的订单场景，如果每条彼此有影响，比如先 check 是否为 0 ，更新的时候再原记录-1 肯定要加锁。如果用户资料修改，更改不依赖之前数据，那加不加都无所谓，纠结什么谁覆盖了谁的更新，谁先谁后没有任何意义。网络本身都可能有波动，不一定先请求的用户就一定先收到，也不代表一定先处理完。

我写 php 的,感觉还好。
但是不需原数据做逻辑,查询就多余了。

看到有说全部更新?
应该不会吧,orm 会跟原数据对比,只更新改变的字段。

字符串并发有什么影响??? 又不是金额之类的数字。
就算是金额,你也要查询出来做校验啊!
你这代码场景,我看不出有并发问题。

这个得看 orm 的实现还有配置？
有的 orm 更新可以提供 TX 的

@Vegetable
我擦,刚注意到你这个描述了。
这已经是 bug 了!
这么写,只能说脑*了。

user 场景来说，一般没什么问题，基本不会有什么并发。但这种全字段更新的，乐观锁控制下会减少点并发的问题。JPA 有自动乐观锁，不一定在这里体现。

这里并发会有数据安全的问题。
如果不是业务场景迫不得已要先查询再根据查询的数据进行更新，不要这么写，直接 update 就好。
有些业务情况下，有时必须要先查询再进行更新，这种情况建议加锁（乐观锁也好、其他方式加悲观锁也好）。

这个不能加 where 条件么？不满足条件不更新，就不会更新到已经被人更新过的数据了？

一楼已经给出答案

我不懂 java
java 中没有原子操作吗

并发问题很大，必须上锁。

先读后写的情况下不都是事务了，没有并发问题。难带这种代码还没事务的吗。

哪有那么多并发问题..一般不会更新别人的数据吧，更新自己的数据客户端卡下，偶尔出问题运维下好了

1. 加锁
2. 用 repeatable_read 事务

但是不管哪种方式都或多或少影响性能

python 的 sqlalchemy 就超级无语，select 的时候就自动开启事务，还关闭不了

根据你业务量决定，在一个就是关于金融积分等要避免，其他无所谓吧

取决于你前置请求是否有类似防抖的操作，如果有校验登陆状态和防抖并发的情况这代码本身并没有什么问题。
登陆状态都合法，也都是用户自己操作的，非敏感数据（金额扣减/状态变更等等）并不需要加太多限制，不然除了降低性能提高复杂度之外没有任何正向收益。

绝对打回

分情况吧。
如果需要处理的话可以用事务+悲观锁或者直接乐观锁来处理。

从功能上来说，就是根据 ID 去更新相关信息，多次短时间内同时调用这是使用场景，跟这个功能没关系。

完全是看实际场景来决定的，user 这种数据这样写一般没问题，就算数据被覆盖问题也不大，订单这种就要注意这种问题

不允许也不建议这样搞

@MooRider 这个 user 是局部变量哪来的并发问题

这不是 spring data 的标准写法么

看了下上面的，原来用 mybatis 的大部份表连 version 没有？

没问题啊 人家说不定方法上有 redis 分布式锁的注解

这是 spring-data 的标准写法，表里会加 version 字段的。

mybatis plus 也有乐观锁啊 看下 userMapper.updateById(u); 会不会触发乐观锁 @Version 标记的字段

你这个查出来再更新肯定有并发问题，直接 updateById 只更新必要字段就好，单个 update 是能保证原子性的。否则的话要用乐观锁/事务来控制。

@csys 赞同，写法是正确的，但是缺少一个真正实现了 unit of work 的框架支撑，而 jpa 就是那个实现了 unit of work 的，同样的写法，他会跟快照对比，看哪个字段变更了，最终生成 update 语句只 update 变更的，不需要加锁

@ForkNMB #68 我也想这么问，要结合上下文来说吧