hibernate实体对象,事务管理,锁
1. 实体的3种状态
Transient(临时的,自由对象,游离的): 与数据库中记录无关的对象. 直接使用数据类的构造函数可以创建一个Transient对象.
Persistent(持久化对象): 由Hibernate框架所管理, 对象与数据库记录对应, 当Session创建事务提交时, 对象的改变将反映到数据库中. 如果Session.delete删除了对象, 则对象变为Transient状态.
Detached(分离的): 当Persistent对象所在的Session被关闭, 则对象变得与数据库分离了.可以把Session看为Persistent对象的容器. Detached对象可以看为具有主键且在数据库有对应的记录, 但又没有被Session管理的Transient对象. 直接创建一个具有主键且在数据库存在的对象, 且不让它被Session管理, 就创建了一个Detached对象.
Transient, Detached 对象都可以被Session的save或update操作后变为Persistent. Persistent对象被成为PO(Persistence Object), 而其他两种被称为VO(Value Object, DTO). PO==>VO 是MVC的标准之一.
判断对象处于Transient状态的条件:
- id属性是否为null;
- 如果配置了id属性的unsaved-value, 那么id属性是否等于unsaved-value;
- 如果配置了Version属性, version属性是否为空;
- 如果配置了Version属性, 且为version定义了unsaved-value, version属性是否等于unsaved-value ;
- 如果存在Interceptor, 那么Interceptor.isUnsaved方法是否返回true.
2. 实体对象的识别, hashCode和equals
传统意义上, 对象的比较使用引用比较(==)或者equals方法, 但对于数据库两个同类型的Persistent持久化对象, 即使某些属性不等, 如果主键值相同, 应该认为是相同的对象. org.Hibernate.engine.Key封装了Hibernate用于区分两个实体对象的识别信息. 其中维持了3个属性, 实体类, 实体名, 实体ID. Key中的值足以确定数据库中的记录, 也扮演在缓存中标识数据的作用.
如果业务逻辑需要自行实现对象的比较, 考虑实现hashCode和equals方法. JavaCollection将通过这两个方法判断对象是否相等. Set集合就不允许集合中出现两个相同对象. Collection调用hashCode两个对象返回相同值时, 再调用equals方法, 两次都判断相等, 则认为两个对象相等. 可以使用apache的组件.
比如:
import org.apache.commons.lang.builder.EqualsBuilder;
import org.apache.commons.lang.builder.HashCodeBuilder;
import org.apache.commons.lang.builder.ToStringBuilder;
...
public String toString(){
return new ToStringBuilder(this)
.append("userid ", getUserid ())
.append("when", getWhen ())
.toString();
}
public boolean equals(Object other){
if(!(other instanceof MyPoJoClass)){
return false;
}
MyPoJoClass castOther=( MyPoJoClass)other;
return new EqualsBuilder()
.appendSuper(super.equals(other))
.append(this.getUserid (),castOther.getUserid() )
.append(this.getWhen (),castOther.getWhen() )
.isEquals();
}
public int hashCode(){
return new HashCodeBuilder()
.appendSuper(super.hashCode() )
.append(getUserid ())
.append(getWhen ())
.toHashCode();
}
3. 脏数据检查
Persistent持久化数据对象的属性发生改变, 不再与数据库一致, 称为脏数据. 事务提交式, Hibernate将判断Session中的PO, 把改变了的数据更新到数据库.
识别脏数据一般两种方法: 1. 数据对象监控, 通过拦截器(Dynamic Proxy或者CGLib可以实现), 通过监控对象的属性设置方法的调用判知对象被更新. 2. 数据版本比对, 这是HIbernate采用的方式.
4. unsaved-value(非保存列值)
数据保存时, Hibernate将根据unsaved-value值来判断对象是否需要保存. 代码中, 使用Session的save, update, saveOrUpdate方法对对象持久化称为显示保存. 而在某些情况下, 比如有级连关系. 代码中没有显示保存语句, Hibernate需要根据对象当前状态判断是否需要保存到数据库, 此时unsaved-value值作为了判断的依据.
Hibernate取出目标对象的id与unsaved-value值比较, 如果相等, 认为目标对象尚未保存, 否则认为已经保存了.
这里的情况往往针对的是对VO的save(插入), 而非指PO的更新. 后者有脏数据检查可以实现更新.
缓存
5. 缓存分类
缓存就是数据库在内存中的临时映像, 位于数据库和数据访问层之间. 相对与在本地内存中获取数据, 数据库调用特别是对远程数据库的访问是一个代价高昂的操作. 所以缓存的合理的利用是ORM不可回避的.
一般地, 可以分几个层次的缓存. 事务级缓存(Transaction Layer Cache), 应用级/进程级缓存(Application/Process Layer Cache), 分布式缓存(Cluster Layer Cache) .
事务级缓存, 针对数据库事务或者应用级事务, 在Hibernate中基于Session的生命周期, 因此也称为内部缓存或者Session Level Cache.
应用级缓存, 跨越多个事务共享, 事务之间的共享策略与应用的事务隔离密切相关. Hibernate中, 应用级缓存在SessionFactory中实现, 所有由此SessionFactory创建的Session实例共享此缓存, 因此也称为SessionFactory Lecvel Cache.
对于多实例并发运行环境中, 必须小心这种缓存机制可能带来的负面效应.
分布式缓存: 多个应用实例, 多个JVM直接共享的缓存. 解决了多实例并发允许过程中的数据同步问题. 由于每个缓存实例的变动都会复制到其余所有节点, 所以效率会降低. 一般, 主流的企业级数据库均具有了数据库级的缓存, 分布式缓存的性能优势并不明显.
Hibernate中维持了两级缓存。第一级缓存由Session实例维护，其中保持了Session 当前所有关联实体的数据，也称为内部缓存。而第二级缓存则存在于SessionFactory层次，由当前所有由本SessionFactory构造的 Session实例共享。
6. Hibernate中缓存的作用
通过id加载数据(load,iterate等)和延迟加载.
一级缓存(内部缓存): 属于事务级缓存. Session的evict可以清除内部缓存的某个对象, 而Session的clear可以清空内部缓存.
二级缓存涵盖了应用级缓存和分布式缓存, 经常考虑数据库是否与其他应用共享, 应用是否部署在集群环境中. 第一种情况下, 往往得放弃二级缓存或者对某些特定的独立表进行缓存, 第二种情况需要考虑性能效率问题. 考虑使用二级缓存的条件:
- 数据不会被第三方修改.
- 数据大小在接受范围内.
- 数据更新频率低.
- 同一数据可能被频繁引用.
- 非关键数据(金融帐号, 密码等不适合缓存).
Hibernate本身补体供二级缓存的实现, 需要的话应该配置第三方缓存实现.
7. 第三方缓存实现
JCS, EHCache, OSCache, JBoss Cache, Swarm Cache. 其中JCS是早期的Hibernate版本的默认二级缓存, 由于JCS的发展停顿, 新版Hibernate已经将JCS去除, 而以EHCache作默认的二级缓存, 后者更稳定, 不过还不能做到分布式缓存.
如果系统在多台设备上部署, 并共享同一个数据库, 则必须使用支持分布式的Cache实现.
| 名称 |
provider_class |
缓冲 |
分布式支持 ? |
| HashTable |
org.hibernate.cache.HashtableCacheProvider |
Y |
|
| EHCache |
net.sf.ehcache.hibernate.Provider |
Y |
|
| OSCache |
org.hibernate.cache.OSCacheProvider |
Y |
|
| Swarm Cache |
org.hibernate.cache.SwarmCacheProvider |
|
Y |
| JBoss Cache |
org.hibernate.cache.TreeCacheProvider |
Y |
Y |
要在Hibernate中启用二级缓存, 需要在hibernate.cfg.xml中配置session-factory的property子元素, 增加hibernate.cache.provider_class属性, property文本为缓存实现类. 同时, 针对特定的Cache, 还需要针对Cache配置. 比如EHCache配置ehcache.xml:
<ehcache>
<diskStore path="java.io.tmpdir" />
<defaultCache
maxElementsInMemory="10000" ----- 最大允许保存的数据对象数量
eternal="false" ----- 数据是否为常量
timeToIdleSeconds="120" ----- 缓存数据断华时间
timeToLiveSeconds="120" ----- 缓存数据得生存时间
overflowToDisk="true" ----- 内存不足时, 是否启用磁盘缓存
/>
</ehcache>
在映射文件中, 增加, cache子元素, 指定映射实体的缓存同步策略. 可应用于实体类和集合属性. 比如:
<set name="address" ... >
<cache usage="read-only" />
</set>
8. 缓存同步策略
缓存同步策略决定了数据对象在缓存中的存取规则.
read-only: 只读,
read-write: 严格的可读写缓存, 基于时间戳判定机制, 实现了read committed事务隔离等级. 用于对数据同步要求严格的情况, 但不支持分布式缓存. 是应用最多的同步策略.
nonstrict-read-write: 对并发访问下的数据同步要求不是很严格, 且数据更新频率较低时采用.
transactional: 事务性缓存, 必须运行在JTA事务环境中. 事务级缓存的相关操作也被添加到事务之中, 实现了Repeatable read 事务级隔离等级, 有效保障了数据的合法性, 适合与对关键数据的缓存.
| 名称 |
read-only |
read-write |
nonstrict-read-write |
transactional |
| HashTable |
Y |
Y |
Y |
|
| EHCache |
Y |
Y |
Y |
|
| OSCache |
Y |
Y |
Y |
|
| Swarm Cache |
Y |
Y |
|
|
| JBoss Cache |
Y |
|
|
Y |
事务管理, 加锁
9. 数据库事务的基本特性ACID
Atomic: 原子性. 事务中的各个操作不可分割. 要么都成功,要么都失败.
Consistency: 一致性. 数据库从一种状态转变为另一种状态, 只有合法的数据才可写入数据库, 数据有任何违例都应该回滚回最初状态.
Isolation: 隔离性.事务允许多个用户对同一数据并发访问, 各个事务互相独立, 且不破坏数据的正确性和完整性.
Durability: 成功提交的事务的持久性. 可掉电保存.
10. 事务的隔离等级
并发事务之间的隔离.Hibernate中事务隔离依赖于底层数据库提供的事务隔离机制. 3种数据库不确定的情况:
脏读取(dirty read): 一个事务读取了另一个并行的事务还未提交的数据. (MySql, Oracle都不会.)
不可重复读取(non-repeatable read): 一个事务再次读取曾经读取过的数据, 发现数据已经被另一个已经提交的事务改变(修改或者删除了). (mysql, Oracle都不会.)
虚读(phantom read): 一个事务重新执行一个查询, 返回一套复合查询条件的记录, 与但其中同时包含了其他最近提交的事务所产生的新记录. 这里以前读取的数据没被改变. (mysql, Oracle都不会.)
标准SQL92规范中, 定义了以下4种ANSI事务隔离等级:
非提交读取(Read Uncommited): 最低等级的事务隔离, 上述3种情况都可能出现. 数据的一致性将不在.
提交读取(Read Commited): 避免读取脏数据. 此时, 一个事务不会读取到另一个并行事务已修改但未提交的数据. 一个SELECT查询只能看到查询之前提交了的数据, 对未提交的数据和查询执行期间其他并行事务未提交的修改不可见. 这是大多数主流数据库的默认事务等级, 也适用大多数系统.
可重复读取(Repeatable Read): 避免了脏数据和不可重复读取. 此时, 一个事务不能更新已经被另一个事务读取但未提交的数据并让后者可见.
串行读取(Serializable): 最高等级的事务隔离, 杜绝了上述三种情况. 这个级别上, 所有的事务就像各自在一个独立的数据库上执行一样.
Oracle支持提交读取和串行读取两种, 还支持自己的READ_ONLY隔离层次, 这个层次的事务具有可重复读取和串行读取的事务处理能力, 但是不能进行数据更新.
11. Hibernate管理事务
作为JDBC的轻量级封装, Hibernate本身不具备事务管理能力, 实际的事务管理交由底层的JDBC或者JTA. 默认事务处理基于JDBC Transaction. 可以通过配置文件hibernate.cfg.xml设定采用JTA作为事务管理. property子元素name= "hibernate.transaction.factory-class" 设置文本为org.hibernate.transaction. JTATransactionFactory.
基于JDBC的事务很简单, 就是对JDBC的简单封装:
Transaction tx = session.beginTransaction();
...
tx.commit();
注意在Hibernate的SessionFactory.openSession中, Hibernate会初始化数据库连接,且将Autocommit设置为false. 而后, session.beginTransaction();语句Hibernate会再次确认AutoCommit为false. 所以如果session执行数据库修改而不进行事务提交就关闭session, 数据库是不会被影响的.
基于JTA的事务提供了跨Session的事务管理能力: JTA事务管理由JTA容器实现, JTA容器对当前加入事务的众多Connection进行调度, JTA事务周期因此可以横跨多个JDBC Connection. 因此, 基于JTA事务管理的Hibernate, JTA事务可横跨多个Session. 此时, 参与JTA事务的Connection(就是Hibernate的Tranasction) 不应该干涉事务管理, 而统一采用JTA Transaction.
这里假如：
public class ClassA{
public void saveUser(User user){
session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
session.save(user);
tx.commit();
session.close();
}
}
public class ClassB{
public void saveOrder(Order order){
session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
session.save(order);
tx.commit();
session.close();
}
}
public class ClassC{
public void save(){
…… //JNDI: Java Naming and Directory Interface
UserTransaction tx = new InitialContext().lookup(“java:comp/UserTransaction”);
ClassA.save(user);
ClassB.save(order);
tx.commit();
……
}
}
这里有两个类ClassA和ClassB，分别提供了两个方法：saveUser和 saveOrder，用于保存用户信息和订单信息。在ClassC中，我们接连调用了ClassA.saveUser方法和 ClassB.saveOrder 方法，同时引入了JTA 中的UserTransaction 以实现ClassC.save方法中的事务性。问题出现了，ClassA 和ClassB 中分别都调用了Hibernate 的Transaction 功能。在Hibernate 的JTA 封装中，Session.beginTransaction 同样也执行了InitialContext.lookup方法获取UserTransaction实例，Transaction.commit方法同样也 调用了UserTransaction.commit方法。实际上，这就形成了两个嵌套式的JTA Transaction：ClassC 申明了一个事务，而在ClassC 事务周期内，ClassA 和ClassB也企图申明自己的事务，这将导致运行期错误。
因此，如果决定采用JTA Transaction，应避免再重复调用Hibernate 的Transaction功能，上面的代码修改如下：
public class ClassA{
public void save(TUser user){
session = sessionFactory.openSession();
session.save(user);
session.close();
}
……
}
public class ClassB{
public void save (Order order){
session = sessionFactory.openSession();
session.save(order);
session.close();
}
……
}
public class ClassC{
public void save(){
……
UserTransaction tx = new InitialContext().lookup(“……”);
classA.save(user);
classB.save(order);
tx.commit();
……
}
}
上面代码中的ClassC.save方法，也可以改成这样：
public class ClassC{
public void save(){
……
session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();
classA.save(user);
classB.save(order);
tx.commit();
……
}
}
实际上，这是利用Hibernate来完成启动和提交UserTransaction的功能，但这样的做法比原本直接通过InitialContext获取UserTransaction 的做法消耗了更多的资源，得不偿失。
12. 委托给容器管理的JTA事务
hibernate.transaction.factory_class 必须配置为org.hibernate.transaction.CMTTransactionFactory委托给容器管理的JTA事务.
13. 锁（locking）
业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算处理中，我们希望针对某 个cut-off时间点的数据进行处理，而不希望在结算进行过程中（可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机制来 保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓的“锁”，即给我们选定的目标数据上锁，使其无法被其他程序修改。
Hibernate支持两种锁机制：即通常所说的“悲观锁（Pessimistic Locking）”和“乐观锁（Optimistic Locking）”。
悲观锁（Pessimistic Locking）:
悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修 改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数 据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
一个典型的依赖数据库的悲观锁调用：
select * from account where name='Erica' for update
这条sql 语句锁定了account 表中所有符合检索条件（name='Erica'）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。 Hibernate的悲观锁，也是基于数据库的锁机制实现。下面的代码实现了对查询记录的加锁：
String hqlStr ="from TUser as user where user.name='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, ...
from 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子句实现加锁。一旦获得锁, 实际等同于UPGRADE.
上面这两种锁机制是较为常用的，加锁一般通过以下方法实现：
Criteria.setLockMode([String,]LockMode)
Query.setLockMode(String, LockMode)
Session.lock(Object, [String,]LockMode)
注意，只有在查询开始之前（也就是Hiberate生成SQL之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含for update子句的Select SQL加载进来，加锁也就无从谈起。
乐观锁（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完成了修改工作，将数据版本号加1（version=2），连同帐户扣除后余额（balance=$50），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录version更新为2。
4 操作员B完成了操作，也将版本号加1（version=2）试图向数据库提交数据（balance=$80），但此时比对数据库记录版本时发现，操作员B 提交的数据版本号为2，数据库记录当前版本也为2，不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略，因此，操作员B 的提交被驳回。这样，就避免了操作员B 用基于version=1 的旧数据修改的结果覆盖操作员A的操作结果的可能。
从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员A和操作员B操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。
需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐 观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充 分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接 对外公开）。
Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产 力。Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。
现在，我们为之前示例中的TUser加上乐观锁机制。
第一步． 首先为TUser的class描述符添加optimistic-lock属性：
<hibernate-mapping>
<class
name="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乐观锁实现机制。
第二步． 添加一个Version属性描述符
<hibernate-mapping>
<class
name="org.hibernate.sample.TUser"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version"
>
<id
name="id"
column="id"
type="java.lang.Integer"
>
<generator class="native">
</generator>
</id>
<version
column="version"
name="version"
type="java.lang.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字段
tx.commit();
每次对TUser进行更新的时候，我们可以发现，数据库中的version都在递增。而如果我们尝试在tx.commit 之前，启动另外一个Session，对名为Erica 的用户进行操作，以模拟并发更新时的情形：
Session session = getSession();
Criteria criteria = session.createCriteria(Tuser.class);
criteria.add(Expression.eq("name", "Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(Tuser.class);
criteria2.add(Expression.eq("name", "Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();
Tuser user = (Tuser) userList.get(0);
Tuser user2 = (Tuser) userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();
执行以上代码，代码将在tx.commit()处抛出StaleObjectStateException异常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。