13518219792
你说的这个version是mysql底层的锁机制提供的，并不是java提供的。
创新互联是一家专业提供南岗企业网站建设,专注与网站制作、网站建设、H5网站设计、小程序制作等业务。10年已为南岗众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。
使用数据版本（Version）记录机制实现，这是mysql乐观锁最常用的一种实现方式。所谓的数据版本就是给数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，版本号重新读取再做更新。
关于mysql中的乐观锁和悲观锁面试的时候被问到的概率还是比较大的。
mysql的悲观锁：
其实理解起来非常简单，当数据被外界修改持保守态度，包括自身系统当前的其他事务，以及来自外部系统的事务处理，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制，但是也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在自身系统中实现了加锁机制，也无法保证外部系统不会修改数据。
来点实际的，当我们使用悲观锁的时候我们首先必须关闭mysql数据库的自动提交属性，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
关闭命令为：set autocommit=0;
悲观锁可以使用select…for update实现，在执行的时候会锁定数据，虽然会锁定数据，但是不影响其他事务的普通查询使用。此处说普通查询就是平时我们用的：select * from table 语句。在我们使用悲观锁的时候事务中的语句例如：
//开始事务
begin;/begin work;/start transaction; (三选一)
//查询信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事务
commit;/commit work;(二选一)
此处的查询语句for update关键字，在事务中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一条数据时会等待其它事务结束后才执行，一般的SELECT查询则不受影响。
执行事务时关键字select…for update会锁定数据，防止其他事务更改数据。但是锁定数据也是有规则的。
查询条件与锁定范围：
1、具体的主键值为查询条件
比如查询条件为主键ID=1等等，如果此条数据存在，则锁定当前行数据，如果不存在，则不锁定。
2、不具体的主键值为查询条件
比如查询条件为主键ID1等等，此时会锁定整张数据表。
3、查询条件中无主键
会锁定整张数据表。
4、如果查询条件中使用了索引为查询条件
明确指定索引并且查到，则锁定整条数据。如果找不到指定索引数据，则不加锁。
悲观锁的确保了数据的安全性，在数据被操作的时候锁定数据不被访问，但是这样会带来很大的性能问题。因此悲观锁在实际开发中使用是相对比较少的。
mysql的乐观锁：
相对悲观锁而言，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会对数据的冲突与否进行检测，如果发现冲突，则让返回用户错误的信息，让用户决定如何去做。
一般来说，实现乐观锁的方法是在数据表中增加一个version字段，每当数据更新的时候这个字段执行加1操作。这样当数据更改的时候，另外一个事务访问此条数据进行更改的话就会操作失败，从而避免了并发操作错误。当然，还可以将version字段改为时间戳，不过原理都是一样的。
例如有表student，字段：
id,name,version
1 a 1
当事务一进行更新操作：update student set name='ygz' where id = #{id} and version = #{version};
此时操作完后数据会变为id = 1,name = ygz,version = 2，当另外一个事务二同样执行更新操作的时候，却发现version != 1，此时事务二就会操作失败，从而保证了数据的正确性。
悲观锁和乐观锁都是要根据具体业务来选择使用，本文仅作简单介绍。
乐观锁与悲观锁不同的是，它是一种逻辑上的锁，而不需要数据库提供锁机制来支持
当数据很重要，回滚或重试一次需要很大的开销时，需要保证操作的ACID性质，此时应该采用悲观锁
而当数据对即时的一致性要求不高，重试一次不太影响整体性能时，可以采用乐观锁来保证最终一致性，同时有利于提高并发性
通常，乐观锁采用版本号/时间戳的形式实现：给数据额外增加一个版本号字段进行控制；更新时，若提交的数据所带的版本号与当前记录的版本号一致，则允许变更执行并更新版本号；若不一致，则意味着产生冲突，根据业务需求直接丢弃并返回失败，或者尝试合并
在MySQL的实践中，常见的一种使用乐观锁的方法，是在需要使用乐观锁的表中，新增一个version字段
例如：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
storing_amount int not null,
version int not null
);
当需要更新销售中的商品数量（selling_amount）时，使用如下的SQL语句：
update product_amount set selling_amount = #{selling_amount}, version = #{new_version} where id=#{id} and version = #{old_version};
若该语句返回1，则表示更新成功；若返回0，则表示前后的version不一致，产生冲突，更新失败
对于更新仓库中的商品数据（storing_amount）时，也是同理
不过，这样为每行记录都统一设置一个version字段的乐观锁方式，存在一个问题：上例中，如果同时需要单独对selling_amount及storing_amount进行update（两条SQL语句分别单独执行），那么后执行的一条会因为先执行的一条更新了version字段而失败，而这种失败显然是没有必要的，白白浪费了开销
一种比较好的方式是为每个需要乐观锁的字段单独设置版本号，例如对上例的改造：
create table product_amount (
id int not null primary key auto_increment,
product_name varchar(64) not null,
selling_amount int not null,
selling_version int not null,
storing_amount int not null,
storing_version int not null
);
selling_amount和storing_amount分别拥有自己的乐观锁版本号（selling_version和storing_version），更新时分别只关注自己的版本号，这样就不会因为版本号被其它字段修改而失败，提高了并发性
以上不是重点，重点是 对事务控制语句不熟悉。
SAVEPOINT identifier : 在事务中 创建保存点。一个事务中 允许有多个保存点。
RELEASE SAVEPOINT identifier : 删除保存点。当事务中 没有指定的 保存点，执行该语句 会抛异常。
ROLLBACK TO identifier : 把事务回滚到 保存点。
Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:
That is a simple task that issue two reads from table T, with a delay of 1 minute between them.
If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.
在Repeatable Read隔离级别下，一个事务可能会遇到幻读（Phantom Read）的问题。
幻读是指，在一个事务中，第一次查询某条记录，发现没有，但是，当试图更新这条不存在的记录时，竟然能成功，并且，再次读取同一条记录，它就神奇地出现了。
我们仍然先准备好students表的数据：
然后，分别开启两个MySQL客户端连接，按顺序依次执行事务A和事务B：
事务B在第3步第一次读取id=99的记录时，读到的记录为空，说明不存在id=99的记录。随后，事务A在第4步插入了一条id=99的记录并提交。事务B在第6步再次读取id=99的记录时，读到的记录仍然为空，但是，事务B在第7步试图更新这条不存在的记录时，竟然成功了，并且，事务B在第8步再次读取id=99的记录时，记录出现了。
可见，幻读就是没有读到的记录，以为不存在，但其实是可以更新成功的，并且，更新成功后，再次读取，就出现了。
在冲突较少的情况下，使用乐观锁。乐观锁 因为没有 加锁 释放锁，也减少了 加锁 释放锁的开销。
冲突较多时，如果使用乐观锁 需要不停地尝试，所以 使用悲观锁。
如果乐观锁 进行尝试时 的花销较大，也是使用悲观锁。
