java多用户同时修改一条数据时乐观锁怎么用的？

你说的这个version是mysql底层的锁机制提供的，并不是java提供的。

使用数据版本（Version）记录机制实现，这是mysql乐观锁最常用的一种实现方式。所谓的数据版本就是给数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，版本号重新读取再做更新。

下面通过一个例子来说明

场景如下：

用户账户有余额，当发生交易时，需要实时更新余额。这里如果发生并发问题，那么会造成用户余额和实际交易的不一致，这对公司和客户来说都是很危险的。

那么如何避免：

网上查了下，有以下两种方法：

1、使用悲观锁

当需要变更余额时，通过代码在事务中对当前需要更新的记录设置for update行锁，然后开始正常的查询和更新 *** 作

这样，其他的事务只能等待该事务完成后方可 *** 作

当然要特别注意，如果使用了Spring的事务注解，需要配置一下：

<!-- (事务管理)transaction manager, use JtaTransactionManager for global tx -->

<bean id="transactionManager"

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

<property name="dataSource" ref="dataSource" />

</bean>

<!-- 使用annotation定义事务 -->

<tx:annotation-driven transaction-manager="transactionManager" />

在指定代码处添加事务注解

@Transactional

@Override

public boolean increaseBalanceByLock(Long userId, BigDecimal amount)

throws ValidateException {

long time = System.currentTimeMillis()

//获取对记录的锁定

UserBalance balance = userBalanceDao.getLock(userId)

LOGGER.info("[lock] start. time: {}", time)

if (null == balance) {

throw new ValidateException(

ValidateErrorCode.ERRORCODE_BALANCE_NOTEXIST,

"user balance is not exist")

}

boolean result = userBalanceDao.increaseBalanceByLock(balance, amount)

long timeEnd = System.currentTimeMillis()

LOGGER.info("[lock] end. time: {}", timeEnd)

return result

}

MyBatis中的锁定方式，实际测试该方法确实可以有效控制，不过在大并发量的情况下，可能会有性能问题吧

<select id="getLock" resultMap="BaseResultMap" parameterType="java.lang.Long">

<![CDATA[

select * from user_balance where id=#{id,jdbcType=BIGINT} for update

]]>

</select>

2、使用乐观锁

这个方法也同样可以解决场景中描述的问题（我认为比较适合并不频繁的 *** 作）：

设计表的时候增加一个version（版本控制字段），每次需要更新余额的时候，先获取对象，update的时候根据version和id为条件去更新，如果更新回来的数量为0，说明version已经变更

需要重复一次更新 *** 作，如下：sql脚本

update user_balance set Balance = #{balance,jdbcType=DECIMAL},Version = Version+1 where Id = #{id,jdbcType=BIGINT} and Version = #{version,jdbcType=BIGINT}

这是一种不使用数据库锁的方法，解决方式也很巧妙。当然，在大量并发的情况下，一次扣款需要重复多次的 *** 作才能成功，还是有不足之处的。不知道还有没有更好的方法。

乐观锁和悲观锁的区别如下：

1、悲观锁是当线程拿到资源时，就对资源上锁，并在提交后，才释放锁资源，其他线程才能使用资源。

2、乐观锁是当线程拿到资源时，上乐观锁，在提交之前，其他的锁也可以 *** 作这个资源，当有冲突的时候，并发机制会保留前一个提交，打回后一个提交，让后一个线程重新获取资源后，再 *** 作，然后提交。和git上传代码一样，两个线程都不是直接获取资源本身，而是先获取资源的两个copy版本，然后在这两个copy版本上修改。

3、悲观锁和乐观锁在并发量低的时候，性能差不多，但是在并发量高的时候，乐观锁的性能远远优于悲观锁。

4、常用的synchronized是悲观锁，lock是乐观锁。

---