Java Mybatis延迟加载的原理是什么？-CSDN博客

本文链接：https://blog.csdn.net/Rubypyrrha/article/details/147756556

MyBatis 延迟加载（Lazy Loading），它允许你在访问关联对象（例如一对一、一对多关系）时，只有当真正需要使用这些关联对象的数据时才执行额外的查询。这种方式可以有效地减少不必要的数据库查询，从而提高性能。

延迟加载原理

MyBatis 的延迟加载（Lazy Loading）原理其实不复杂，可以用一个生活中的例子来比喻理解。

比喻解释

想象一下你正在计划一次旅行，并决定去书店买一本旅游指南。在书店里，你可以选择两种方式获取信息：

立即购买所有可能需要的资料：这意味着你不仅会买一本关于目的地的旅游指南，还会买下所有相关的地图、历史书籍、文化介绍等。这样做可能会导致你携带大量不必要的资料，增加了负担。
仅购买当前需要的信息：你只购买了一本基本的旅游指南。当你到达目的地后，如果发现自己对某个特定的历史遗址特别感兴趣，再去当地的书店或博物馆购买更详细的资料。这样做的好处是避免了不必要的开支和负担，只在真正需要的时候获取最详细的信息。

MyBatis 延迟加载的工作原理

在 MyBatis 中，延迟加载就像是第二种方式。它不会立即加载所有的关联数据，而是等到你实际访问这些关联的数据时才进行加载。这种方式可以显著减少初次查询时的数据量，从而提高应用性能。

继续用上面的旅游比喻，假设我们有两张表：TouristGuide（旅游指南）和 DetailInfo（详细信息）。每个旅游指南都可能有关联的详细信息，但并不是每次查看旅游指南都需要这些详细信息。

当我们查询一个旅游指南的信息时，MyBatis 不会立刻查询其关联的详细信息，除非我们在代码中明确地访问了这些详细信息。这就像你在出发前只带上了最基本的旅游指南，在旅途中根据需要再购买额外的详细资料一样。

// 查询旅游指南时不自动加载详细信息
TouristGuide guide = touristGuideMapper.selectById(1);
// 当首次尝试访问详细信息时，MyBatis 才执行额外的查询操作
List<DetailInfo> details = guide.getDetails();

在这个过程中，只有当调用了 getDetails() 方法时，MyBatis 才会执行相应的 SQL 查询以加载相关联的详细信息。这种机制有效地减少了初始数据加载量，提高了应用的响应速度，特别是在处理复杂的对象图关系时显得尤为重要。

原理总结

延迟加载的核心思想是“按需加载”。当你配置了延迟加载后，MyBatis 不会在你第一次加载某个实体时立即加载它的关联数据。相反，它会创建一个代理对象来代替实际的关联对象。只有当你尝试访问这个代理对象的属性或方法时，才会触发真正的数据库查询，以此加载关联的数据。

在 MyBatis 中，实现延迟加载主要依赖于两个方面：

代理机制：MyBatis 使用 CGLIB 或 Javassist 库为关联对象创建动态代理。当你的代码试图访问延迟加载的对象时，代理对象将拦截这个调用，并执行必要的 SQL 查询以加载所需的数据。
配置：为了启用延迟加载，你需要在 MyBatis 配置文件中进行相应的设置。这通常包括设置 lazyLoadingEnabled 为 true 来全局开启延迟加载功能，同时可以通过设置 aggressiveLazyLoading 控制是否积极地加载所有嵌套的关联对象。

下面是一个简单的配置示例，用于在 MyBatis 的配置文件中启用延迟加载：

<settings>
    <!-- 开启延迟加载 -->
    <setting name="lazyLoadingEnabled" value="true"/>
    <!-- 关闭积极加载（即仅在访问属性时加载） -->
    <setting name="aggressiveLazyLoading" value="false"/>
</settings>

需要注意的是，虽然延迟加载可以带来性能上的好处，但它也可能导致 N+1 查询问题，即最初的一次查询之后，每个实体的每次关联加载都会产生一次额外的查询请求。为了避免这种情况，你可以考虑使用 MyBatis 的嵌套结果映射（Nested Result Mapping）或其他优化策略。此外，由于延迟加载依赖于代理对象，所以在使用延迟加载时要注意避免序列化相关的问题，因为代理对象可能无法被正确序列化。

应用场景：

1. 关联对象或集合较少被使用

当你的主实体对象与一个或多个其他实体对象有关联关系，但这些关联的数据并不总是被需要时，可以考虑使用延迟加载。例如，在博客系统中，文章（Post）和评论（Comment）之间的关系。并不是每次展示文章列表时都需要同时显示评论，只有在用户点击查看某篇文章详情时，才需要加载该文章的所有评论。

2. 减少不必要的数据库查询

假设你有一个包含大量关联信息的对象模型，直接加载所有相关联的数据可能会导致大量的数据库查询，这不仅会增加数据库服务器的负担，还可能拖慢应用的响应时间。通过延迟加载，你可以仅在确实需要时才执行必要的查询，从而减轻数据库的压力。

3. 提高内存使用效率

由于延迟加载只在实际访问关联属性时才会初始化关联对象，因此可以帮助节省内存空间。对于大型项目或有限资源的应用来说，这一点尤为重要。

4. 复杂查询优化

在处理复杂的多表连接查询时，如果部分结果集不是每个场景都必需的，延迟加载提供了一种方式来优化查询逻辑。这样做的好处是可以简化初始查询，并根据需求动态加载额外的信息。

简单代码示例

我们以第一个应用场景为例展示一个简单的代码示例。

应用场景

假设我们有一个简单的博客系统，其中包含两个实体：Blog（博客）和 Comment（评论）。每个博客可以有多个评论，但并非每次展示博客列表时都需要显示所有评论。因此，在这种情况下，我们可以使用 MyBatis 的延迟加载特性来优化数据获取过程。

代码过程

首先，我们需要在 MyBatis 配置文件中开启延迟加载：

<settings>
    <!-- 开启延迟加载 -->
    <setting name="lazyLoadingEnabled" value="true"/>
    <!-- 当访问到集合或关联对象时立即触发加载 -->
    <setting name="aggressiveLazyLoading" value="false"/>
</settings>

接下来是我们的实体类定义：

public class Blog {
    private Integer id;
    private String title;
    // 假设每篇博客可能有多个评论
    private List<Comment> comments;

    // getter 和 setter 方法
}

public class Comment {
    private Integer id;
    private String content;
    private Integer blogId; // 关联的博客ID

    // getter 和 setter 方法
}

然后，我们在 MyBatis 的映射文件中配置 Blog 和 Comment 的关系，并指定使用延迟加载：

<mapper namespace="com.example.BlogMapper">
    <!-- 查询博客信息 -->
    <select id="selectBlog" resultMap="blogResultMap">
        SELECT * FROM blogs WHERE id = #{id}
    </select>

    <resultMap id="blogResultMap" type="Blog">
        <id property="id" column="id"/>
        <result property="title" column="title"/>
        <!-- 使用延迟加载获取博客的评论 -->
        <collection property="comments" ofType="Comment" select="selectCommentsByBlogId" column="id" fetchType="lazy"/>
    </resultMap>

    <!-- 根据博客ID查询对应的评论 -->
    <select id="selectCommentsByBlogId" resultType="Comment">
        SELECT * FROM comments WHERE blog_id = #{id}
    </select>
</mapper>

在这个例子中，当我们调用 selectBlog 方法查询博客信息时，如果没有访问 comments 属性，MyBatis 不会执行查询评论的 SQL 语句。只有当我们实际尝试访问某个博客的评论时，MyBatis 才会执行相应的查询操作。

注意事项

事务管理：确保在整个延迟加载的过程中，数据库连接保持有效。如果在读取 comments 之前关闭了数据库连接，将会导致延迟加载失败。
代理机制：MyBatis 实现延迟加载依赖于 JDK 动态代理或 CGLIB，这意味着某些序列化或反射操作可能会失效。
测试与调试：由于延迟加载的行为取决于运行时的操作，建议编写单元测试以验证延迟加载逻辑是否按预期工作。

通过这种方式，MyBatis 提供了一种灵活的方式来优化数据访问模式，尤其是在处理复杂的对象图关系时。根据具体的应用需求，合理地运用延迟加载可以显著提升系统的性能和响应速度。

延迟加载如何避免N+1查询的问题？

正如我们一开始提到的那样，延迟加载可能会导致N+1 查询问题，接下来我们就详细解答下这个问题

什么是 N+1 查询问题？

简单来说，N+1 查询问题是这样的：当你有一个父对象和它的多个子对象，并且你需要获取这些对象的数据时，如果你首先执行了一个查询来获取所有的父对象（这就是"1"），然后对每个父对象执行一个单独的查询来获取其子对象（这就产生了"N"个查询，其中N是父对象的数量），那么总共就会有 N+1 次数据库查询。这在父对象数量较多时，会导致严重的性能问题。

示例

假设我们有一个 Author 类和一个 Book 类，每个作者可以有多本书。如果我们的代码逻辑如下：

List<Author> authors = authorMapper.selectAllAuthors(); // 这是第1次查询
for (Author author : authors) {
    List<Book> books = bookMapper.selectBooksByAuthorId(author.getId()); // 对于每个author，都会执行一次查询，即N次查询
}

这里，selectAllAuthors() 是第一次查询，之后每调用一次 selectBooksByAuthorId() 就是一次额外的查询。如果有20个作者，就会有1次初始查询加上20次获取书籍的查询，共21次查询。

解决方案

1. 使用嵌套结果映射（Nested Result Mapping）

MyBatis 提供了强大的结果映射功能，允许你通过一次查询就同时获取主对象及其关联的对象数据。这通常涉及到使用 <association> 或 <collection> 标签来定义如何映射这些关系。例如：

<resultMap id="blogResult" type="Blog">
    <id property="id" column="blog_id"/>
    <result property="title" column="blog_title"/>
    <!-- 嵌套选择作者 -->
    <association property="author" javaType="Author">
        <id property="id" column="author_id"/>
        <result property="username" column="author_username"/>
    </association>
</resultMap>

<select id="selectBlog" resultMap="blogResult">
    SELECT B.id as blog_id, B.title as blog_title,
           A.id as author_id, A.username as author_username
    FROM Blog B
    LEFT JOIN Author A ON B.author_id = A.id
    WHERE B.id = #{id}
</select>

在这个例子中，我们通过一条 SQL 语句就获取到了博客和它的作者信息，避免了对每个博客都要单独查询作者的 N+1 问题。

2. 批量抓取（Batch Fetching）

另一种方法是利用 MyBatis 的批量抓取特性，在需要加载多个相同类型的关联对象时，只执行一次查询。这可以通过在配置中设置 batchSize 属性来实现。例如：

<settings>
    <!-- 开启延迟加载 -->
    <setting name="lazyLoadingEnabled" value="true"/>
    <!-- 设置批量大小 -->
    <setting name="defaultExecutorType" value="batch"/>
</settings>

不过需要注意的是，这种方式适用于某些特定情况，并不总是能完全解决 N+1 查询问题。