Day_59_MyBatis_03

最新推荐文章于 2023-10-17 15:27:27 发布

势不可挡の内鬼

最新推荐文章于 2023-10-17 15:27:27 发布

阅读量98

点赞数

分类专栏：学习日志文章标签：数据库 java

本文链接：https://blog.csdn.net/m0_51589970/article/details/121984195

版权

学习日志专栏收录该内容

52 篇文章 0 订阅

订阅专栏

一、完成连接池的配置和使用
1、连接池
创建一个java.sql.Connection对象的代价是如此巨大，是因为创建一个Connection对象的过程，在底层就相当于和数据库建立的通信连接，在建立通信连接的过程，消耗了这么多的时间，而往往我们建立连接后（即创建Connection对象后），就执行一个简单的SQL语句，然后就要抛弃掉，对于一个复杂的数据库应用，情况就完全不同了。频繁的建立、关闭连接，会极大的减低系统的性能，因为对于连接的使用成了系统性能的瓶颈。

对于需要频繁地跟数据库交互的应用程序，可以在创建了Connection对象，并操作完数据库后，可以不释放掉资源，而是将它放到内存中，当下次需要操作数据库时，可以直接从内存中取出Connection对象，不需要再创建了，这样就极大地节省了创建Connection对象的资源消耗。由于内存也是有限和宝贵的，这又对我们对内存中的Connection对象怎么有效地维护提出了很高的要求。

我们将在内存中存放Connection对象的容器称之为连接池（Connection Pool）

总结：

1、连接池是面向数据库连接的

2、连接池是为了优化数据库的连接资源

2、mybatis中的连接池
在 Mybatis 中我们将它的数据源 dataSource 分为以下几类

Mybatis 将它自己的数据源分为三类：

①、UNPOOLED 不使用连接池的数据源

会为每一个数据库操作创建一个新的连接，并关闭它。该方式使用于只有小规模数量并发用

户的简单应用程序上。

②、POOLED 使用连接池的数据源

会创建一个数据库连接池，连接池中的一个连接会被用做数据库操作。一旦数据库操作完

成，Mybatis会将此连接返回给连接池。在开发或测试环境中，常用此方式。

③、JNDI 使用 JNDI 实现的数据源

Mybatis从在应用服务器向配置好的JNDI数据源dataSource获取数据库连接。在生产环境

中优先考虑这种方式。

3、源码分析
3.1、三类数据源的关系
在Mybatis内部定义了一个接口DataSourceFactory以及它的三个实现类UnpooledDataSourceFactory 、PooledDataSourceFactory 、JndiDataSourceFactory

public interface DataSourceFactory {
void setProperties(Properties props);

DataSource getDataSource();

}

public class UnpooledDataSourceFactory implements DataSourceFactory {....}

public class PooledDataSourceFactory extends UnpooledDataSourceFactory{....}

public class JndiDataSourceFactory implements DataSourceFactory{...}

具体结构如下：

与这些数据源工厂类相对应的也定义了相应的数据源对象，其中UnpooledDataSourceFactory和PooledDataSourceFactory工厂返回的分别是UnpooledDataSource和PooledDataSource，而JndiDataSourceFactory则是根据配置返回相应的数据源。

public class PooledDataSource implements DataSource{...}

public class UnpooledDataSource implements DataSource {...}

3.2、mybatis中数据源的创建过程

1、先从配置文件开始

<dataSource type="POOLED">
<property name="driver" value="${driver}"/>
   <property name="url" value="${url}"/>
   <property name="username" value="${username}"/>
   <property name="password" value="${password}"/>
</dataSource>

2、在mybatis初始化的时候，在解析到节点时，会根据相应的type类型设置来创建相应的数据源工厂类实例，如下所示：

在上面代码里，根据type类型去寻找相应的数据源工厂类并实例化一个。具体每一个配置对应什么类，在Configuration类中已经进行了声明，如下所示：

2.1、之后，从数据源工厂类实例中通过getDataSource()方法获取一个DataSource对象；

2.2、MyBatis创建了DataSource实例后，会将其放到Configuration对象内的Environment对象中，供以后使用。如下所示：

2.3、数据源DataSource对象什么时候创建数据库连接

当我们需要创建SqlSession对象并需要执行SQL语句时，这时候MyBatis才会去调用dataSource对象来创建java.sql.Connection对象。也就是说，java.sql.Connection对象的创建一直延迟到执行SQL语句的时候。

对于上面这段代码，我们通过调试会发现，在前两句的时候其实是没有创建数据库连接的，而是在执行openSession.selectOne()方法的时候才触发了数据库连接的创建。

3、非池化的数据源UnpooledDataSource

代码分析

从上面的代码可以知道UnpooledDataSource创建数据库连接的主要流程，具体时序图如下所示：

（a）调用initializeDriver()方法进行驱动的初始化；

判断driver驱动是否已经加载到内存中，如果还没有加载，则会动态地加载driver类，并实例化一个Driver对象，使用DriverManager.registerDriver()方法将其注册到内存中，以供后续使用。

（b）调用DriverManager.getConnection()获取数据库连接；

（c）对数据库连接进行一些设置，并返回数据库连接Connection;

username和password是什么传递给数据源的呢？

这个问题其实上面已经提到过了，在mybatis初始化的时候，就已经解析了元素，并将其下相关的配置作为数据源的配置初始化进去了。也就是下面这段逻辑：

至此，对于UnpooledDataSource数据源算是有比较清楚的了解了。

4、带连接池的PooledDataSource
在mybatis中，定义了一个数据库连接池状态的类PoolState，在这个类里，除维护了数据源实例，还维护着数据库连接。数据库连接被分成了两种状态类型并存放在两个列表中：idleConnections和activeConnections。

idleConnections:

空闲(idle)状态PooledConnection对象被放置到此集合中，表示当前闲置的没有被使用的PooledConnection集合，调用PooledDataSource的getConnection()方法时，会优先从此集合中取PooledConnection对象。当用完一个java.sql.Connection对象时，MyBatis会将其包裹成PooledConnection对象放到此集合中。

activeConnections:

活动(active)状态的PooledConnection对象被放置到名为activeConnectionsArrayList中，表示当前正在被使用的PooledConnection集合，调用PooledDataSource的getConnection()方法时，会优先从idleConnections集合中取PooledConnection对象,如果没有，则看此集合是否已满，如果未满，PooledDataSource会创建出一个PooledConnection，添加到此集合中，并返回。

下面我们看看怎么从连接池中获取一个数据库连接，还是从PooledDataSource类开始看起。

这里都是调用了popConnection()方法，然后返回其代理对象。

private PooledConnection popConnection(String username, String password) throws SQLException {
    boolean countedWait = false;
    PooledConnection conn = null;
    long t = System.currentTimeMillis();
    int localBadConnectionCount = 0;
 
    while (conn == null) {
      synchronized (state) {
        if (!state.idleConnections.isEmpty()) {
          // Pool has available connection
          conn = state.idleConnections.remove(0);
          if (log.isDebugEnabled()) {
            log.debug("Checked out connection " + conn.getRealHashCode() + " from pool.");
          }
        } else {
          // Pool does not have available connection
          if (state.activeConnections.size() < poolMaximumActiveConnections) {
            // Can create new connection
            conn = new PooledConnection(dataSource.getConnection(), this);
            if (log.isDebugEnabled()) {
              log.debug("Created connection " + conn.getRealHashCode() + ".");
            }
          } else {
            // Cannot create new connection
            PooledConnection oldestActiveConnection = state.activeConnections.get(0);
            long longestCheckoutTime = oldestActiveConnection.getCheckoutTime();
            if (longestCheckoutTime > poolMaximumCheckoutTime) {
              // Can claim overdue connection
              state.claimedOverdueConnectionCount++;
              state.accumulatedCheckoutTimeOfOverdueConnections += longestCheckoutTime;
              state.accumulatedCheckoutTime += longestCheckoutTime;
              state.activeConnections.remove(oldestActiveConnection);
              if (!oldestActiveConnection.getRealConnection().getAutoCommit()) {
                try {
                  oldestActiveConnection.getRealConnection().rollback();
                } catch (SQLException e) {
                  log.debug("Bad connection. Could not roll back");
                }
              }
              conn = new PooledConnection(oldestActiveConnection.getRealConnection(), this);
              conn.setCreatedTimestamp(oldestActiveConnection.getCreatedTimestamp());
              conn.setLastUsedTimestamp(oldestActiveConnection.getLastUsedTimestamp());
              oldestActiveConnection.invalidate();
              if (log.isDebugEnabled()) {
                log.debug("Claimed overdue connection " + conn.getRealHashCode() + ".");
              }
            } else {
              // Must wait
              try {
                if (!countedWait) {
                  state.hadToWaitCount++;
                  countedWait = true;
                }
                if (log.isDebugEnabled()) {
                  log.debug("Waiting as long as " + poolTimeToWait + " milliseconds for connection.");
                }
                long wt = System.currentTimeMillis();
                state.wait(poolTimeToWait);
                state.accumulatedWaitTime += System.currentTimeMillis() - wt;
              } catch (InterruptedException e) {
                break;
              }
            }
          }
        }
        if (conn != null) {
          // ping to server and check the connection is valid or not
          if (conn.isValid()) {
            if (!conn.getRealConnection().getAutoCommit()) {
              conn.getRealConnection().rollback();
            }
            conn.setConnectionTypeCode(assembleConnectionTypeCode(dataSource.getUrl(), username, password));
            conn.setCheckoutTimestamp(System.currentTimeMillis());
            conn.setLastUsedTimestamp(System.currentTimeMillis());
            state.activeConnections.add(conn);
            state.requestCount++;
            state.accumulatedRequestTime += System.currentTimeMillis() - t;
          } else {
            if (log.isDebugEnabled()) {
              log.debug("A bad connection (" + conn.getRealHashCode() + ") was returned from the pool, getting another connection.");
            }
            state.badConnectionCount++;
            localBadConnectionCount++;
            conn = null;
            if (localBadConnectionCount > (poolMaximumIdleConnections + poolMaximumLocalBadConnectionTolerance)) {
              if (log.isDebugEnabled()) {
                log.debug("PooledDataSource: Could not get a good connection to the database.");
              }
              throw new SQLException("PooledDataSource: Could not get a good connection to the database.");
            }
          }
        }
      }
 
    }
 
    if (conn == null) {
      if (log.isDebugEnabled()) {
        log.debug("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");
      }
      throw new SQLException("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");
    }
 
    return conn;
  }

我们看下上面的方法都做了什么：

1. 先看是否有空闲(idle)状态下的PooledConnection对象，如果有，就直接返回一个可用的PooledConnection对象；否则进行第2步。

2. 查看活动状态的PooledConnection池activeConnections是否已满；如果没有满，则创建一个新的PooledConnection对象，然后放到activeConnections池中，然后返回此PooledConnection对象；否则进行第三步；

3. 看最先进入activeConnections池中的PooledConnection对象是否已经过期：如果已经过期，从activeConnections池中移除此对象，然后创建一个新的PooledConnection对象，添加到activeConnections中，然后将此对象返回；否则进行第4步；

4. 线程等待，循环2步。

流程图如下：

当我们拿到数据库连接PooledConnection后，我们在使用完之后一般来说就要关闭这个数据库连接，但是，对于池化来说，我们关闭了一个数据库连接并不是真正意义上想关闭这个连接，而是想把它放回到数据库连接池中。

怎么实现呢？mybatis中使用了代理模式有效的解决了该问题。就是返回给外部使用的数据库连接其实是一个代理对象（通过调用getProxyConnection()返回的对象）。这个代理对象是在真实数据库连接创建的时候被创建的，如下所示：

而在调用这个代理对象的各个方法的时候，都是通过反射的方式，从invoke()方法进入，我们来看看：

我们可以看到，这里做了一个特殊处理，那就是判断调用的方法名是否是close()方法，如果是的话，就调用数据源对象的pushConnection()方法将数据库连接放回到连接池中，如下所示：

简单的说下上面这个方法的逻辑：

1. 首先将当前数据库连接从活动数据库连接集合activeConnections中移除；

2. 判断当前数据库连接是否有效，如果无效，则跳转到第4步；如果有效，则继续下面

的判断；

3. 判断当前idleConnections集合中的闲置数据库连接数量是否没超过设置的阈值且是

当前数据库连接池的创建出来的链接，如果是，则将该数据库连接放回到

idleConnections集合中并且通知在此据库连接池上等待的请求对象线程，如果不

是，则将数据库连接关闭；

4. 将连接池中的坏数据库连接数+1，并返回；

总结：

通过分析，大家应该对数据库的连接池技术有个大概的了解，需要知道mybatis中数据库连接池的大致实现流程，也对我们之后的程序开发很有帮助。同时，大家也要养成看源码的习惯，通过对源码进行分析，也可以提升自己的编程功底。

二、Mybatis的事务
1、 JDBC中的事务
在 JDBC 中我们可以通过手动方式将事务的提交改为手动方式，通过 setAutoCommit()方法就可以调整。通过 JDK 文档，我们找到该方法如下：

那么我们的 Mybatis 框架因为是对 JDBC 的封装，所以 Mybatis 框架的事务控制方式，本身也是用 JDBC 的setAutoCommit()方法来设置事务提交方式的。

2、 Mybatis中的事务提交方式
Mybatis 中事务的提交方式，本质上就是调用 JDBC 的 setAutoCommit()来实现事务控制。我们运行之前所写的代码：

private SqlSession session = null;
	@Before
	public void init() throws IOException {
		String resource = "mybatis-config.xml";
		InputStream inputStream = Resources.getResourceAsStream(resource);
		SqlSessionFactory sessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
		session = sessionFactory.openSession(true);
	}
	@After
	public void destory() {
		//session.commit();
		session.close();
	}
	@Test
	public void test() {
		User user = new User("安娜", "123", "jack", 0);
		//System.out.println(user);
		session.insert("com.tledu.mjw.pojo.User.add", user);
	}

这里我们设置了自动提交事务之后，就不需要在进行commit操作了

3、事务的回滚
对于我们开发过程，也会遇到报错的情况，这个时候为了保证数据的一致性我们就需要进行事务的回滚，比如我们有一个操作需要同时更新用户表和地址表，这个时候更新用户表的时候成功了，但是更新地址表的时候出现了一个特别长的字段，导致更新失败，这个时候，我们需要将数据进行回滚。

private SqlSession session = null;
	@Before
	public void init() throws IOException {
		String resource = "mybatis-config.xml";
		InputStream inputStream = Resources.getResourceAsStream(resource);
		SqlSessionFactory sessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
		session = sessionFactory.openSession();
	}
	@After
	public void destory() {
		//session.commit();
		session.close();
	}
	@Test
	public void test() {
		try {
			User user = new User("安东尼", "123", "jack", 0);
			session.insert("com.tledu.mjw.pojo.User.add", user);
			throw new Exception();
		} catch (Exception e) {
			e.printStackTrace();
			session.rollback();
		}
	}

三、事务的隔离级别
上面的事务在单个情况下一般不会出现什么问题，但是如果同时运行多个，就会出现问题了。我们知道并发操作总是会出现各种各样的问题，对于事务来说就会出现下面三个典型的问题：

（1）脏读

有俩事务T1,T2。如果T1读了一条数据，这条数据是T2更新的但是还没提交，突然T2觉得不合适进行事务回滚了，也就是不提交了。此时T1读的数据就是无效的数据。

（2）不可重复读

有俩事务T1,T2。如果T1读了一条数据，之后T2更新了这条数据，T1再次读取就发现值变了。

（3）幻读

有俩事务T1,T2。如果T1读了一条数据，之后T2插入了一些新的数据，T1再次读取就会多出现一些数据。

mybatis中也可以设置隔离级别，只不过增加了一个没有事务的属性

session.openSession(这里可以写级别);

public enum TransactionIsolationLevel {
  NONE(Connection.TRANSACTION_NONE),
  READ_COMMITTED(Connection.TRANSACTION_READ_COMMITTED),
  READ_UNCOMMITTED(Connection.TRANSACTION_READ_UNCOMMITTED),
  REPEATABLE_READ(Connection.TRANSACTION_REPEATABLE_READ),
  SERIALIZABLE(Connection.TRANSACTION_SERIALIZABLE);
 
  private final int level;
 
  TransactionIsolationLevel(int level) {
    this.level = level;
  }
 
  public int getLevel() {
    return level;
  }
}

四、延迟加载策略
4.1 什么是延迟加载
延迟加载：

就是在需要用到数据时才进行加载，不需要用到数据时就不加载数据。延迟加载也称懒加载.

好处：

先从单表查询，需要时再从关联表去关联查询，大大提高数据库性能，因为查询单表要比关

联查询多张表速度要快。

坏处：

因为只有当需要用到数据时，才会进行数据库查询，这样在大批量数据查询时，因为查询工

作也要消耗时间，所以可能造成用户等待时间变长，造成用户体验下降。

4.2、需求
需求：

查询产品类型(Category)信息并且关联查询产品(Product)信息。

如果先查询产品类型(Category)信息即可满足要求，当我们需要查询产品(Product)信息时再查询

产品(Product)信息。把对产品(Product)信息按需去查询就是延迟加载。

实现多表操作时，我们使用了resultMap来实现一对一，一对多关系的操作。主要是通过

association、collection 实现一对一及一对多映射。

association、collection 具备延迟加载功能。

4.3、collection 实现懒加载
4.3.1、未实现延迟加载的时候
我们之前未实现延迟加载的时候，每次操作，都会直接查询出我们需要的数据

可以看到控制台打印了两条sql

4.3.2、开启延迟加载

找到对应设置

通过lazyLoadingEnabled、aggressiveLazyLoading可以对延迟加载进行配置

<properties resource="jdbc.properties"></properties>
<settings>
<setting name="lazyLoadingEnabled" value="true"/>
<setting name="aggressiveLazyLoading" value="false"/>
</settings>

注意：settings标签一定要放在properties下面

添加了懒加载配置之后，我们在进行列表查询的过程中就不会再做大量的关联查询了，可以

提升列表查询的效率，在我们用到具体字段之后才会进行关联查询。

在CategoryMapper.xml中添加如下代码：

<mapper namespace="com.tledu.mjw.dao">
        <resultMap type="Category" id="categoryBean" autoMapping="true">
            <id column="id" property="id"/>
            <result column="name" property="name"/>
            <collection property="products" ofType="Product" column="id" select="query" autoMapping="true" fetchType="lazy"/>
        </resultMap>
        
        <select id="lazyListCategory" resultMap="categoryBean" parameterType="int">
        	select * from t_category where id = #{id}
        </select>
        
        <select id="query" resultType="Product" parameterType="int">
        	select * from t_product where cid = #{id}
        </select>
    </mapper>

4.3.3、aggressiveLazyLoading

属性开启之后，我们获取到变量的任意属性，就会触发懒加载，而关闭之后，我们

只有触发到关联属性时，才会触发懒加载

4.3.4、配置每个关联字段的加载方式

<resultMap type="Category" id="categoryBean" autoMapping="true">
<id column="id" property="id"/>
<result column="name" property="name"/>
<collection property="products" ofType="Product" column="id" select="query"
fetchType="lazy"/>
</resultMap>

4.3.5、association实现懒加载

association的懒加载实现和collection基本类似

势不可挡の内鬼

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Day_59_MyBatis_03

一、完成连接池的配置和使用1、连接池创建一个java.sql.Connection对象的代价是如此巨大，是因为创建一个Connection对象的过程，在底层就相当于和数据库建立的通信连接，在建立通信连接的过程，消耗了这么多的时间，而往往我们建立连接后（即创建Connection对象后），就执行一个简单的SQL语句，然后就要抛弃掉，对于一个复杂的数据库应用，情况就完全不同了。频繁的建立、关闭连接，会极大的减低系统的性能，因为对于连接的使用成了系统性能的瓶颈。对于需要频繁地跟数据库交互的应用程序，可以在
复制链接

扫一扫