MyBatis原理深入解析(二)
8 MyBatis数据源与连接池
8.1 MyBatis数据源DataSource分类
MyBatis把数据源DataSource分为三种:
UNPOOLED不使用连接池的数据源
POOLED使用连接池的数据源
JNDI使用JNDI实现的数据源
相应地,MyBatis内部分别定义了实现了java.sql.DataSource接口的UnpooledDataSource,PooledDataSource类来表示UNPOOLED、POOLED类型的数据源。 如下图所示:
对于JNDI类型的数据源DataSource,则是通过JNDI上下文中取值。
8.2 数据源DataSource的创建过程
MyBatis数据源DataSource对象的创建发生在MyBatis初始化的过程中。下面让我们一步步地了解MyBatis是如何创建数据源DataSource的。
在Mybatis的XML配置文件中,使用<dataSource>元素来配置数据源:
1. MyBatis在初始化时,解析此文件,根据<dataSource>的type属性来创建相应类型的的数据源DataSource,即:
1
|
type=”POOLED” :MyBatis会创建PooledDataSource实例
|
2. 顺便说一下,MyBatis是通过工厂模式来创建数据源DataSource对象的,MyBatis定义了抽象的工厂接口:org.apache.ibatis.datasource.DataSourceFactory,通过其getDataSource()方法返回数据源DataSource:
1
|
public interface DataSourceFactory {
|
上述三种不同类型的type,则有对应的以下dataSource工厂:
POOLED:PooledDataSourceFactory
UNPOOLED:UnpooledDataSourceFactory
JNDI:JndiDataSourceFactory
3. MyBatis创建了DataSource实例后,会将其放到Configuration对象内的Environment对象中,供以后使用。
8.3 DataSource什么时候创建Connection对象
当我们需要创建SqlSession对象并需要执行SQL语句时,这时候MyBatis才会去调用dataSource对象来创建java.sql.Connection对象。也就是说,java.sql.Connection对象的创建一直延迟到执行SQL语句的时候。
比如,我们有如下方法执行一个简单的SQL语句:
1
|
String resource = "mybatis-config.xml";
|
前4句都不会导致java.sql.Connection对象的创建,只有当第5句sqlSession.selectList("SELECT * FROM STUDENTS"),才会触发MyBatis在底层执行下面这个方法来创建java.sql.Connection对象:
1
|
protected void openConnection() throws SQLException {
|
8.4 不使用连接池的UnpooledDataSource
当<dataSource>的type属性被配置成了UNPOOLED,MyBatis首先会实例化一个UnpooledDataSourceFactory工厂实例,然后通过getDataSource()方法返回一个UnpooledDataSource实例对象引用,我们假定为dataSource。
使用UnpooledDataSource的getConnection(),每调用一次就会产生一个新的Connection实例对象。
UnPooledDataSource的getConnection()方法实现如下:
1
|
/*
|
如上代码所示,UnpooledDataSource会做以下事情:
初始化驱动:判断
driver驱动是否已经加载到内存中,如果还没有加载,则会动态地加载driver类,并实例化一个Driver对象,使用DriverManager.registerDriver()方法将其注册到内存中,以供后续使用。创建
Connection对象:使用DriverManager.getConnection()方法创建连接。配置
Connection对象:设置是否自动提交autoCommit和隔离级别isolationLevel。返回
Connection对象。
总结:从上述的代码中可以看到,我们每调用一次getConnection()方法,都会通过DriverManager.getConnection()返回新的java.sql.Connection实例。
8.5 为什么要使用连接池?
1. 创建一个java.sql.Connection实例对象的代价
首先让我们来看一下创建一个java.sql.Connection对象的资源消耗。我们通过连接Oracle数据库,创建创建Connection对象,来看创建一个Connection对象、执行SQL语句各消耗多长时间。代码如下:
1
|
public static void main(String[] args) throws Exception
|
从此结果可以清楚地看出,创建一个Connection对象,用了250毫秒;而执行SQL的时间用了170毫秒。
创建一个Connection对象用了250毫秒!这个时间对计算机来说可以说是一个非常奢侈的!
这仅仅是一个Connection对象就有这么大的代价,设想一下另外一种情况:如果我们在Web应用程序中,为用户的每一个请求就操作一次数据库,当有10000个在线用户并发操作的话,对计算机而言,仅仅创建Connection对象不包括做业务的时间就要损耗10000 × 250ms = 250 0000ms = 2500s = 41.6667min,竟然要41分钟!!!如果对高用户群体使用这样的系统,简直就是开玩笑!
2. 问题分析:
创建一个java.sql.Connection对象的代价是如此巨大,是因为创建一个Connection对象的过程,在底层就相当于和数据库建立的通信连接,在建立通信连接的过程,消耗了这么多的时间,而往往我们建立连接后(即创建Connection对象后),就执行一个简单的SQL语句,然后就要抛弃掉,这是一个非常大的资源浪费!
3. 解决方案:
对于需要频繁地跟数据库交互的应用程序,可以在创建了
Connection对象,并操作完数据库后,可以不释放掉资源,而是将它放到内存中,当下次需要操作数据库时,可以直接从内存中取出Connection对象,不需要再创建了,这样就极大地节省了创建Connection对象的资源消耗。由于内存也是有限和宝贵的,这又对我们对内存中的Connection对象怎么有效地维护提出了很高的要求。我们将在内存中存放Connection对象的容器称之为连接池(Connection Pool)。下面让我们来看一下MyBatis的连接池是怎样实现的。
8.6 使用了连接池的PooledDataSource
同样地,我们也是使用PooledDataSource的getConnection()方法来返回Connection对象。现在让我们看一下它的基本原理:
PooledDataSource将java.sql.Connection对象包裹成PooledConnection对象放到了PoolState类型的容器中维护。
MyBatis将连接池中的PooledConnection分为两种状态:空闲状态(idle)和活动状态(active),这两种状态的PooledConnection对象分别被存储到PoolState容器内的idleConnections和activeConnections两个List集合中:
idleConnections:空闲(idle)状态PooledConnection对象被放置到此集合中,表示当前闲置的没有被使用的PooledConnection集合,调用PooledDataSource的getConnection()方法时,会优先从此集合中取PooledConnection对象。当用完一个java.sql.Connection对象时,MyBatis会将其包裹成PooledConnection对象放到此集合中。
activeConnections:活动(active)状态的PooledConnection对象被放置到名为activeConnections的ArrayList中,表示当前正在被使用的PooledConnection集合,调用PooledDataSource的getConnection()方法时,会优先从idleConnections集合中取PooledConnection对象,如果没有,则看此集合是否已满,如果未满,PooledDataSource会创建出一个PooledConnection,添加到此集合中,并返回。
1. 获取java.sql.Connection对象的过程
下面让我们看一下PooledDataSource的getConnection()方法获取Connection对象的实现:
1
|
public Connection getConnection() throws SQLException {
|
上述的popConnection()方法,会从连接池中返回一个可用的PooledConnection对象,然后再调用getProxyConnection()方法最终返回Conection对象。(至于为什么会有getProxyConnection(),请关注下一节)。
现在让我们看一下popConnection()方法到底做了什么:
- 先看是否有空闲(
idle)状态下的PooledConnection对象,如果有,就直接返回一个可用的PooledConnection对象;否则进行第2步。- 查看活动状态的
PooledConnection池activeConnections是否已满;如果没有满,则创建一个新的PooledConnection对象,然后放到activeConnections池中,然后返回此PooledConnection对象;否则进行第三步;- 看最先进入
activeConnections池中的PooledConnection对象是否已经过期:如果已经过期,从activeConnections池中移除此对象,然后创建一个新的PooledConnection对象,添加到activeConnections中,然后将此对象返回;否则进行第4步。- 线程等待,循环2步
1
|
/*
|
如上所示,对于
PooledDataSource的getConnection()方法内,先是调用类PooledDataSource的popConnection()方法返回了一个PooledConnection对象,然后调用了PooledConnection的getProxyConnection()来返回Connection对象。
2. java.sql.Connection对象的回收
当我们的程序中使用完Connection对象时,如果不使用数据库连接池,我们一般会调用connection.close()方法,关闭connection连接,释放资源。如下所示:
1
|
private void test() throws ClassNotFoundException, SQLException
|
调用过close()方法的Connection对象所持有的资源会被全部释放掉,Connection对象也就不能再使用。
那么,如果我们使用了连接池,我们在用完了Connection对象时,需要将它放在连接池中,该怎样做呢?
为了和一般的使用Conneciton对象的方式保持一致,我们希望当Connection使用完后,调用close()方法,而实际上Connection资源并没有被释放,而实际上被添加到了连接池中。这样可以做到吗?答案是可以。上述的要求从另外一个角度来描述就是:能否提供一种机制,让我们知道Connection对象调用了什么方法,从而根据不同的方法自定义相应的处理机制。恰好代理机制就可以完成上述要求。
怎样实现Connection对象调用了close()方法,而实际是将其添加到连接池中:
这是要使用代理模式,为真正的
Connection对象创建一个代理对象,代理对象所有的方法都是调用相应的真正Connection对象的方法实现。当代理对象执行close()方法时,要特殊处理,不调用真正Connection对象的close()方法,而是将Connection对象添加到连接池中。
MyBatis的PooledDataSource的PoolState内部维护的对象是PooledConnection类型的对象,而PooledConnection则是对真正的数据库连接java.sql.Connection实例对象的包裹器。
PooledConnection对象内持有一个真正的数据库连接java.sql.Connection实例对象和一个java.sql.Connection的代理,其部分定义如下:
1
|
class PooledConnection implements InvocationHandler {
|
PooledConenction实现了InvocationHandler接口,并且,proxyConnection对象也是根据这个它来生成的代理对象:
1
|
public PooledConnection(Connection connection, PooledDataSource dataSource) {
|
实际上,我们调用PooledDataSource的getConnection()方法返回的就是这个proxyConnection对象。当我们调用此proxyConnection对象上的任何方法时,都会调用PooledConnection对象内invoke()方法。
让我们看一下PooledConnection类中的invoke()方法定义:
1
|
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
|
从上述代码可以看到,当我们使用了
pooledDataSource.getConnection()返回的Connection对象的close()方法时,不会调用真正Connection的close()方法,而是将此Connection对象放到连接池中。
8.7 JNDI类型的数据源DataSource
对于JNDI类型的数据源DataSource的获取就比较简单,MyBatis定义了一个JndiDataSourceFactory工厂来创建通过JNDI形式生成的DataSource。下面让我们看一下JndiDataSourceFactory的关键代码:
1
|
if (properties.containsKey(INITIAL_CONTEXT) && properties.containsKey(DATA_SOURCE))
|
9 MyBatis事务管理机制
9.1 概述
对数据库的事务而言,应该具有以下几点:创建(create)、提交(commit)、回滚(rollback)、关闭(close)。对应地,MyBatis将事务抽象成了Transaction接口:
MyBatis的事务管理分为两种形式:
使用
JDBC的事务管理机制:即利用java.sql.Connection对象完成对事务的提交(commit())、回滚(rollback())、关闭(close())等。
使用MANAGED的事务管理机制:这种机制MyBatis自身不会去实现事务管理,而是让程序的容器如(JBOSS,Weblogic)来实现对事务的管理。
9.2 事务的配置、创建和使用
1. 事务的配置
我们在使用MyBatis时,一般会在MyBatis的XML配置文件中定义类似如下的信息:
<environment>节点定义了连接某个数据库的信息,其子节点<transactionManager>的type会决定我们用什么类型的事务管理机制。
2. 事务工厂的创建
MyBatis事务的创建是交给TransactionFactory事务工厂来创建的,如果我们将<transactionManager>的type配置为JDBC,那么,在MyBatis初始化解析<environment>节点时,会根据type="JDBC"创建一个JdbcTransactionFactory工厂,其源码如下:
1
|
/**
|
如上述代码所示,如果type = "JDBC",则MyBatis会创建一个JdbcTransactionFactory.class实例;如果type="MANAGED",则MyBatis会创建一个MangedTransactionFactory.class实例。
MyBatis对<transactionManager>节点的解析会生成TransactionFactory实例;而对<dataSource>解析会生成datasouce实例,作为<environment>节点,会根据TransactionFactory和DataSource实例创建一个Environment对象,代码如下所示:
1
|
private void environmentsElement(XNode context) throws Exception {
|
Environment表示着一个数据库的连接,生成后的Environment对象会被设置到Configuration实例中,以供后续的使用。
上述一直在讲事务工厂TransactionFactory来创建的Transaction,现在让我们看一下MyBatis中的TransactionFactory的定义吧。
3. 事务工厂TransactionFactory
事务工厂Transaction定义了创建Transaction的两个方法:一个是通过指定的Connection对象创建Transaction,另外是通过数据源DataSource来创建Transaction。与JDBC和MANAGED两种Transaction相对应,TransactionFactory有两个对应的实现的子类:
4. 事务Transaction的创建
通过事务工厂TransactionFactory很容易获取到Transaction对象实例。我们以JdbcTransaction为例,看一下JdbcTransactionFactory是怎样生成JdbcTransaction的,代码如下:
1
|
public class JdbcTransactionFactory implements TransactionFactory {
|
如上说是,JdbcTransactionFactory会创建JDBC类型的Transaction,即JdbcTransaction。类似地,ManagedTransactionFactory也会创建ManagedTransaction。下面我们会分别深入JdbcTranaction和ManagedTransaction,看它们到底是怎样实现事务管理的。
5. JdbcTransaction
JdbcTransaction直接使用JDBC的提交和回滚事务管理机制。它依赖与从dataSource中取得的连接connection来管理transaction的作用域,connection对象的获取被延迟到调用getConnection()方法。如果autocommit设置为on,开启状态的话,它会忽略commit和rollback。
直观地讲,就是JdbcTransaction是使用的java.sql.Connection上的commit和rollback功能,JdbcTransaction只是相当于对java.sql.Connection事务处理进行了一次包装(wrapper),Transaction的事务管理都是通过java.sql.Connection实现的。JdbcTransaction的代码实现如下:
1
|
public class JdbcTransaction implements Transaction {
|
6. ManagedTransaction
ManagedTransaction让容器来管理事务Transaction的整个生命周期,意思就是说,使用ManagedTransaction的commit和rollback功能不会对事务有任何的影响,它什么都不会做,它将事务管理的权利移交给了容器来实现。看如下Managed的实现代码大家就会一目了然:
1
|
/**
|
注意:如果我们使用
MyBatis构建本地程序,即不是WEB程序,若将type设置成MANAGED,那么,我们执行的任何update操作,即使我们最后执行了commit操作,数据也不会保留,不会对数据库造成任何影响。因为我们将MyBatis配置成了MANAGED,即MyBatis自己不管理事务,而我们又是运行的本地程序,没有事务管理功能,所以对数据库的update操作都是无效的。
10 MyBatis关联查询
MyBatis提供了高级的关联查询功能,可以很方便地将数据库获取的结果集映射到定义的Java Bean中。下面通过一个实例,来展示一下Mybatis对于常见的一对多和多对一关系复杂映射是怎样处理的。
设计一个简单的博客系统,一个用户可以开多个博客,在博客中可以发表文章,允许发表评论,可以为文章加标签。博客系统主要有以下几张表构成:
Author表:作者信息表,记录作者的信息,用户名和密码,邮箱等。
Blog表:博客表,一个作者可以开多个博客,即Author和Blog的关系是一对多。
Post表:文章记录表,记录文章发表时间,标题,正文等信息;一个博客下可以有很多篇文章,Blog和Post的关系是一对多。
Comments表:文章评论表,记录文章的评论,一篇文章可以有很多个评论:Post和Comments的对应关系是一对多。
Tag表:标签表,表示文章的标签分类,一篇文章可以有多个标签,而一个标签可以应用到不同的文章上,所以Tag和Post的关系是多对多的关系;(Tag和Post的多对多关系通过Post_Tag表体现)
一般情况下,我们会根据每一张表的结构创建与此相对应的JavaBean(或者Pojo),来完成对表的基本CRUD操作。
上述对单个表的JavaBean定义有时候不能满足业务上的需求。在业务上,一个Blog对象应该有其作者的信息和一个文章列表,如下图所示:
如果想得到这样的类的实例,则最起码要有一下几步:
- 通过
Blog的id到Blog表里查询Blog信息,将查询到的blogId和title赋到Blog对象内;- 根据查询到到
blog信息中的authorId去Author表获取对应的author信息,获取Author对象,然后赋到Blog对象内;- 根据
blogId去Post表里查询对应的Post文章列表,将List<Post>对象赋到Blog对象中;
这样的话,在底层最起码调用三次查询语句,请看下列的代码:
1
|
/*
|
从上面的代码可以看出,想获取一个BlogInfo对象比较麻烦,总共要调用三次数据库查询,得到需要的信息,然后再组装BlogInfo对象。
10.1 嵌套语句查询
Mybatis提供了一种机制,叫做嵌套语句查询,可以大大简化上述的操作,加入配置及代码如下:
1
|
<resultMap type="com.foo.bean.BlogInfo" id="BlogInfo">
|
1
|
/*
|
通过上述的代码完全可以实现前面的那个查询。这里我们在代码里只需要 blogInfo = (BlogInfo)session.selectOne("com.foo.bean.BlogMapper.queryBlogInfoById",id);一句即可获取到复杂的blogInfo对象。
嵌套语句查询的原理:
在上面的代码中,Mybatis会执行以下流程:
- 先执行
queryBlogInfoById对应的语句从Blog表里获取到ResultSet结果集;- 取出
ResultSet下一条有效记录,然后根据resultMap定义的映射规格,通过这条记录的数据来构建对应的一个BlogInfo对象。- 当要对
BlogInfo中的author属性进行赋值的时候,发现有一个关联的查询,此时Mybatis会先执行这个select查询语句,得到返回的结果,将结果设置到BlogInfo的author属性上;- 对
BlogInfo的posts进行赋值时,也有上述类似的过程。- 重复
2步骤,直至ResultSet.next() == false;
这种关联的嵌套查询,有一个非常好的作用就是:可以重用select语句,通过简单的select语句之间的组合来构造复杂的对象。上面嵌套的两个select语句com.foo.bean.AuthorMapper.selectByPrimaryKey和com.foo.bean.PostMapper.selectByBlogId完全可以独立使用。
N+1问题:
它的弊端也比较明显:即所谓的
N+1问题。关联的嵌套查询显示得到一个结果集,然后根据这个结果集的每一条记录进行关联查询。
现在假设嵌套查询就一个(即resultMap内部就一个association标签),现查询的结果集返回条数为N,那么关联查询语句将会被执行N次,加上自身返回结果集查询1次,共需要访问数据库N+1次。如果N比较大的话,这样的数据库访问消耗是非常大的!所以使用这种嵌套语句查询的使用者一定要考虑慎重考虑,确保N值不会很大。
以上面的例子为例,select语句本身会返回com.foo.bean.BlogMapper.queryBlogInfoById条数为1的结果集,由于它有两条关联的语句查询,它需要共访问数据库1 * (1 + 1) = 3次数据库。
10.2 嵌套结果查询
嵌套语句的查询会导致数据库访问次数不定,进而有可能影响到性能。Mybatis还支持一种嵌套结果的查询:即对于一对多,多对多,多对一的情况的查询,Mybatis通过联合查询,将结果从数据库内一次性查出来,然后根据其一对多,多对一,多对多的关系和ResultMap中的配置,进行结果的转换,构建需要的对象。
重新定义BlogInfo的结果映射resultMap:
1
|
<resultMap type="com.foo.bean.BlogInfo" id="BlogInfo">
|
对应的sql语句如下:
1
|
<select id="queryAllBlogInfo" resultMap="BlogInfo">
|
1
|
/*
|
嵌套结果查询的执行步骤:
根据表的对应关系,进行
join操作,获取到结果集;根据结果集的信息和
BlogInfo的resultMap定义信息,对返回的结果集在内存中进行组装、赋值,构造BlogInfo;返回构造出来的结果
List<BlogInfo>结果。
对于关联的结果查询,如果是多对一的关系,则通过形如<association property="author" column="blog_author_id" javaType="com.foo.bean.Author">进行配置,Mybatis会通过column属性对应的author_id值去从内存中取数据,并且封装成Author对象;
如果是一对多的关系,就如Blog和Post之间的关系,通过形如 <collection property="posts" column="blog_post_id" offType="com.foo.bean.Post">进行配置,MyBatis通过blog_id去内存中取Post对象,封装成List<Post>;
对于关联结果的查询,只需要查询数据库一次,然后对结果的整合和组装全部放在了内存中。
原文作者:文/陶邦仁(简书作者)
原文标题:终结篇:MyBatis原理深入解析(二)












浙公网安备 33010602011771号