乐观锁与悲观锁
乐观锁和悲观锁说的什么意思
统不会修改数据）。
2、乐观锁（ Optimistic Locking ）
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长ຫໍສະໝຸດ 务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。 �
面试必备之乐观锁与悲观锁
何谓悲观锁与乐观锁乐观锁对应于生活中乐观的人总是想着事情往好的方向发展，悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。
这两种人各有优缺点，不能不以场景而定说一种人好于另外一种人。
悲观锁总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。
乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。
在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
两种锁的使用场景从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
但如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。
乐观锁常见的两种实现方式乐观锁一般会使用版本号机制或CAS算法实现。
1. 版本号机制一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。
当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。
笔试题总结
一.区别数据库悲观锁和乐观锁：1、悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
2、乐观锁（Optimistic Locking ）相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。
悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。
但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
而乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本（Version ）记录机制实现。
何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。
此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
根据定义可以看出区别：1，悲观锁是数据库实现的，而乐观锁可以在程序中通过版本控制实现。
2，加锁的时机不同。
悲观锁会在事务的最初就要更新的数据全部锁定，乐观锁可以在操作的最后才加锁。
（这块没怎么想清楚）这点类似于java早期的synchronized锁和现在的并发包中的锁。
synchronized锁会在程序执行到同步的方法时就加锁，并发包中则是通过cvs操作（其实就是版本控制）。
这样看synchronized属于悲观锁，并发包中的锁属于乐观锁。
二．数据库索引1.可以利用索引快速访问数据库表中的特定信息。
索引是对数据库表中一个或多个列（例如，employee ? 表的姓氏? (lname) ? 列）的值进行排序的结构。
乐观锁和悲观锁的区别
乐观锁和悲观锁的区别乐观锁在关系数据库管理系统⾥，乐观并发控制（⼜名”乐观锁”，Optimistic Concurrency Control，缩写”OCC”）是⼀种并发控制的⽅法。
它假设多⽤户并发的事务在处理时不会彼此互相影响，各事务能够在不产⽣锁的情况下处理各⾃影响的那部分数据。
在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务⼜修改了该数据。
如果其他事务有更新的话，正在提交的事务会进⾏回滚。
乐观事务控制最早是由孔祥重（H.T.Kung）教授提出。
乐观并发控制的阶段乐观并发控制的事务包括以下阶段：1. 读取：事务将数据读⼊缓存，这时系统会给事务分派⼀个时间戳。
2. 校验：事务执⾏完毕后，进⾏提交。
这时同步校验所有事务，如果事务所读取的数据在读取之后⼜被其他事务修改，则产⽣冲突，事务被中断回滚。
3. 写⼊：通过校验阶段后，将更新的数据写⼊数据库。
乐观并发控制多数⽤于数据争⽤不⼤、冲突较少的环境中，这种环境中，偶尔回滚事务的成本会低于读取数据时锁定数据的成本，因此可以获得⽐其他并发控制⽅法更⾼的吞吐量。
相对于悲观锁，在对数据库进⾏处理的时候，乐观锁并不会使⽤数据库提供的锁机制。
⼀般的实现乐观锁的⽅式就是记录数据版本。
数据版本,为数据增加的⼀个版本标识。
当读取数据时，将版本标识的值⼀同读出，数据每更新⼀次，同时对版本标识进⾏更新。
当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第⼀次取出来的版本标识进⾏⽐对，如果数据库表当前版本号与第⼀次取出来的版本标识值相等，则予以更新，否则认为是过期数据。
实现数据版本有两种⽅式，第⼀种是使⽤版本号，第⼆种是使⽤时间戳。
使⽤版本号实现乐观锁使⽤版本号时，可以在数据初始化时指定⼀个版本号，每次对数据的更新操作都对版本号执⾏+1操作。
并判断当前版本号是不是该数据的最新的版本号。
使⽤版本号实现乐观锁使⽤版本号时，可以在数据初始化时指定⼀个版本号，每次对数据的更新操作都对版本号执⾏+1操作。
数据库防止并发冲突
数据库防止并发冲突数据库防止并发冲突的主要方法是使用事务的隔离性（Isolation）和锁机制（Locking）。
一．事务的隔离性：１．当多个事务同时对数据库进行操作时，隔离性确保每个事务都独立运行，不受其他事务的影响。
２．数据库管理系统（DBMS）通过确保事务的原子性、一致性、隔离性和持久性（ACID属性）来管理并发操作。
二．锁机制：１．锁是用来控制对共享资源的并发访问的机制。
当事务正在修改某个数据项时，它可以锁定该数据项，以防止其他事务同时修改它。
２．根据锁定粒度，锁可以分为表锁和行锁。
表锁锁定整个表，而行锁只锁定被访问的行。
行锁通常提供更好的并发性，但实现起来更复杂。
３．锁的类型包括共享锁（允许多个事务同时读取资源）和排他锁（只允许一个事务修改资源）。
三．乐观锁和悲观锁：１．乐观锁：它假设多个事务同时冲突修改同一个数据项的可能性很小。
因此，它不会预先锁定数据，而是在数据提交时检查是否有冲突。
如果发生冲突，则事务会被回滚。
乐观锁通常通过版本号或时间戳来实现。
２．悲观锁：它假设多个事务同时冲突修改同一个数据项的可能性很大。
因此，它会在数据被访问时立即锁定数据，直到事务完成。
四．其他并发控制策略：１．时间戳排序：每个事务都有一个唯一的时间戳。
当事务尝试修改一个数据项时，它会检查该数据项的时间戳。
如果数据项的时间戳晚于事务的时间戳，那么事务就会回滚。
２．多版本并发控制（MVCC）：这是许多现代数据库系统（如PostgreSQL和MySQL的InnoDB存储引擎）使用的一种技术。
每个数据项可以有多个版本，每个事务都看到数据的一个特定版本。
这允许多个事务同时读取同一数据项，而不会相互干扰。
为了有效地防止并发冲突，需要根据具体的应用场景和需求选择适当的并发控制策略。
锁：主流锁整体认知（悲观锁与乐观锁、CAS算法、自旋锁、synchronized分析）
锁：主流锁整体认知（悲观锁与乐观锁、CAS算法、⾃旋锁、synchronized分析）1、悲观锁与乐观锁（1）悲观锁与乐观锁悲观锁悲观锁认为⾃⼰在获取数据的时候⼀定有别的线程来修改数据，在获取数据的时候会先加锁，确保数据不会被别的线程修改锁实现:关键字synchronized、接⼝Lock的实现类适⽤场景:写操作较多，先加锁可以保证写操作时数据正确乐观锁乐观锁认为⾃已在获取数据时不会有别的线程修改数据，所以不会添加锁，只是在更新数据的时候去判断之前有没有别的线程更新了这个数据锁实现: CAS算法，例如AtomicInteger 类的原⼦⾃增是同过CAS⾃旋实现适⽤场景:读操作较多，不加锁的特点能够使其读操作的性能⼤幅提升（2）执⾏流程悲观锁多个线程尝试获取同步资源的锁（给同步资源加锁）某个线程加锁成功并执⾏操作，其他线程进⼊等待获取到锁的线程执⾏完成之后会释放锁，然后CPU唤醒等待的线程，被唤醒的线程再次尝试获取锁乐观锁线程直接获取同步资源数据执⾏各⾃的操作更新内存中的同步资源之前先判断资源是否被其他线程修改。
没有被修改，就可以更新内存中同步资源的值；被其他线程修改的话就根据实现⽅法执⾏不同的操作（3）锁产⽣的原因进程的数据是独⽴的，线程的数据是共享的，因此只说线程的安全性，解决线程安全有以下⽅法：不跨线程共享变量,线程共享的变量改为⽅法局部级变量使状态变量为不可变的，使⽤final修饰 (将变量变为常量)在任何访问状态变量的时候使⽤同步，使⽤synchronized修饰⽅法，或使⽤同步代码块。
每个共享的可变变量都需要由唯⼀个确定的锁保护，使⽤Lock锁。
锁是⼀种保护机制，在多线程的情况下能够保证数据的⼀致性（4）锁的分类悲观锁、乐观锁、可重⼊锁、⾃旋锁、独享锁、读写锁、阻塞锁、公平锁、⾮公平锁、分段锁、对象锁、类所、轻量级锁、分布式锁等等⾮常多。
乐观锁:跟悲观锁相反，假设数据⼀般情况下不会造成冲突，只有在数据进⾏提交更新时，才会正式对数据的冲突与否进⾏检测，如果发现冲突了，则返回错误信息，让⽤户决定如何去做。
谈谈乐观锁和悲观锁
谈谈乐观锁和悲观锁前言我在网上查阅了很多关于乐观锁和悲观锁的介绍和使用场景，大都用这样的一句话来概括了- 悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。
- 乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。
但是随着进一步的思考，我对这些结论又产生不同的看法，下面我就说说我对这个概念的理解和看法。
悲观锁你和你老婆都去银行取钱，一个账户里只有5000元，然后使用`select for update`可以避免丢失更新。
但是这个时候，你查询余额的时候接了一个电话，打了30分钟。
在这30分钟内，你啥事都没干，这样你的账户相当于被锁住了，你老婆得等你，不仅你老婆要等你，这个时候，你的商业合作伙伴要给你打钱，你的整个账户都处于锁定状态，所有依赖于你的账户的修改操作，都得暂停，因为你的账户在这个过程一直被排它锁占领者，这样你的账户在这30分钟内，处于瘫痪状态，除了你独占的事物中可以操作，其他事物全部瘫痪，如果并发很大，你的账户是一个业务很繁忙的账户（连锁商店统一扫码收款账户），很多收款业务都无法进行。
在`select for update`所在的事物中select的数据，是被你这个事物独占的，如果该事物耗时很长，并且，你锁定的行又处在很多大并发的写操作中，麻烦就来了，这种`select for update`的锁定方式，防止丢失更新，表现形式上，是一种悲观锁定方式，它在操作的时候，必须要独占数据，它总认为有人会来修改它，很悲观犹如惊弓之鸟，很有可能是，他10000次操作，只有1次，出现了有人修改，9999次，都没人动，但是他依然很悲观，采用了独占式锁定。
乐观锁都用过svn，我们从svn服务器中下载了文件到本地，然后对他进行修改，然后提交回svn。
数据库中并发控制的乐观锁与悲观锁比较
数据库中并发控制的乐观锁与悲观锁比较在数据库管理系统中，为了保证并发操作的正确性和一致性，需要进行并发控制。
乐观锁和悲观锁是两种常见的并发控制方法。
本文将比较乐观锁和悲观锁的特点、适用场景以及优缺点。
一、乐观锁概述乐观锁是一种乐观的并发控制方式，它假设并发访问不会发生冲突，只在事务提交时检查是否有冲突。
乐观锁使用版本号或时间戳作为标记来检测冲突。
当发现冲突时，乐观锁会回滚事务并重新执行。
二、悲观锁概述悲观锁是一种悲观的并发控制方式，它假设并发访问会发生冲突，因此在操作之前会对数据进行加锁，阻止其他事务的访问。
只有当前事务完成操作后，其他事务才能访问该数据。
三、乐观锁与悲观锁的比较1. 特点比较：a. 乐观锁：假设并发冲突较少，并发操作不会发生阻塞，只在事务提交时检测冲突。
b. 悲观锁：假设并发冲突较多，加锁导致其他事务被阻塞，直到当前事务完成操作。
2. 适用场景比较：a. 乐观锁：适用于读请求较多、冲突较少的场景，例如读多写少的应用。
b. 悲观锁：适用于写请求较多、冲突较多的场景，例如高并发写入数据库的应用。
3. 实现方式比较：a. 乐观锁：使用版本号或时间戳来检测冲突，事务提交时检查数据是否被修改。
b. 悲观锁：使用锁机制来保证数据的独占性，例如共享锁和排它锁。
4. 性能比较：a. 乐观锁：由于避免加锁操作，可以提高并发性能，适用于并发情况较少的场景。
b. 悲观锁：由于加锁操作可能导致阻塞，性能较乐观锁稍差，适用于并发情况较多的场景。
5. 开发复杂度比较：a. 乐观锁：需要在数据表中添加版本号或时间戳字段，并在事务提交时检查冲突。
b. 悲观锁：需要使用锁机制，例如共享锁和排它锁，并在代码中显式加锁和解锁。
6. 异常处理比较：a. 乐观锁：如果发现冲突，事务将回滚并重新执行，需要处理并发冲突的异常情况。
b. 悲观锁：如果发现冲突，其他事务需要等待锁被释放，可能会引起超时等异常情况。
7. 数据的可见性比较：a. 乐观锁：在事务提交前，其他事务不可见已提交的数据，可能会造成数据不一致的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
乐观锁与悲观锁锁（locking）业务逻辑的实现过程中，往往需要保证数据访问的排他性。
如在金融系统的日终结算处理中，我们希望针对某个cut-off时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。
此时，我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。
Hibernate支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking）”和“乐观锁（Optimistic Locking）”。
悲观锁（Pessimistic Locking）悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中（事务），将数据处于锁定状态。
悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的倚赖数据库的悲观锁调用：select * from account where name=”Erica” for update这条sql 语句锁定了ac count 表中所有符合检索条件（name=”Erica”）的记录。
本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。
Hibernate的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：String hqlStr ="from TUser as user where ='Erica'";Query query = session.createQuery(hqlStr);query.setLockMode("user",LockMode.UPGRADE); //加锁List userList = query.list();//执行查询，获取数据query.setLockMode对查询语句中，特定别名所对应的记录进行加锁（我们为TUser类指定了一个别名“user”），这里也就是对返回的所有user记录进行加锁。
观察运行期Hibernate生成的SQL语句：select tuser0_.id as id, tuser0_.name as name, tuser0_.group_idas group_id, tuser0_.user_type as user_type, tuser0_.sex as sexfrom t_user tuser0_ where (tuser0_.name='Erica' ) for update这里Hibernate通过使用数据库的for update子句实现了悲观锁机制。
Hibernate的加锁模式有：Ø LockMode.NONE ：无锁机制。
Ø LockMode.WRITE ：Hibernate在Insert和Update记录的时候会自动获取。
Ø LockMode.READ ：Hibernate在读取记录的时候会自动获取。
以上这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。
Ø LockMode.UPGRADE ：利用数据库的for update子句加锁。
Ø LockMode. UPGRADE_NOWAIT ：Oracle的特定实现，利用Oracle的for update nowait子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：Criteria.setLockModeQuery.setLockModeSession.lock注意，只有在查询开始之前（也就是Hiberate 生成SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update 子句的Select SQL加载进来，所谓数据库加锁也就无从谈起。
乐观锁（Optimistic Locking）相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。
悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。
但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。
乐观锁（Optimistic Locking）乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本（Version）记录机制实现。
何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。
此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段（balance）为$100。
1 操作员A 此时将其读出（version=1），并从其帐户余额中扣除$50（$100-$50）。
2 在操作员A操作的过程中，操作员B也读入此用户信息（version=1），并从其帐户余额中扣除$20（$100-$20）。
3 操作员A完成了修改工作，将数据版本号加一（version=2），连同帐户扣除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。
4 操作员B完成了操作，也将版本号加一（version=2）试图向数据库提交数据（balance=$80），但此时比对数据库记录版本时发现，操作员B提交的数据版本号为2，数据库记录当前版本也为2，不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略，因此，操作员B 的提交被驳回。
这样，就避免了操作员B 用基于version=1 的旧数据修改的结果覆盖操作员A的操作结果的可能。
从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员A 和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。
在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。
Hibernate 在其数据访问引擎中内置了乐观锁实现。
如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。
Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。
现在，我们为之前示例中的TUser加上乐观锁机制。
1．首先为TUser的class描述符添加optimistic-lock属性：<hibernate-mapping><classname="org.hibernate.sample.TUser"table="t_user"dynamic-update="true"dynamic-insert="true"optimistic-lock="version">……</class></hibernate-mapping>optimistic-lock属性有如下可选取值：Ø none无乐观锁Ø version通过版本机制实现乐观锁Ø dirty通过检查发生变动过的属性实现乐观锁Ø all通过检查所有属性实现乐观锁其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。
因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。
2．添加一个Version属性描述符<hibernate-mapping><classname="org.hibernate.sample.TUser"table="t_user"dynamic-update="true"dynamic-insert="true"optimistic-lock="version"><idname="id"column="id"type="ng.Integer"><generator class="native"></generator></id><versioncolumn="version"name="version"type="ng.Integer"/>……</class></hibernate-mapping>注意version 节点必须出现在ID 节点之后。
这里我们声明了一个version属性，用于存放用户的版本信息，保存在TUser表的version字段中。
此时如果我们尝试编写一段代码，更新TUser表中记录数据，如：Criteria criteria = session.createCriteria(TUser.class);criteria.add(Expression.eq("name","Erica"));List userList = criteria.list();TUser user =(TUser)userList.get(0);Transaction tx = session.beginTransaction();user.setUserType(1); //更新UserType字段mit();每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。