使用Lightrun对Java应用程序进行性能调整

简介

在这篇文章中，我将向你展示使用Lightrun分析一个Java应用程序，这样你就可以发现各种性能调整的改进，你可以应用到你当前的Java应用程序。

在上一篇文章中，我解释了什么是Lightrun，以及你如何使用它来注入动态日志、捕获运行时快照或添加动态指标。

在这篇文章中，我将使用Lightrun作为我的JPA关联获取验证器的替代品。

DefaultLoadEventListener

当使用Hibernate获取JPA实体时，会触发一个 LoadEvent ，由 DefaultLoadEventListener ，处理方式如下。

DefaultLoadEventListener 将检查该实体是否位于当前JPA持久化上下文或第一级缓存中。如果在那里找到了实体，那么就会返回相同的对象引用。

这意味着，两个连续的实体获取调用将总是返回相同的Java Object 引用。这就是JPA和Hibernate提供应用级可重复读取的原因。

如果在第一级缓存中没有找到实体，Hibernate将尝试从第二级缓存中加载它，如果且仅当第二级缓存被启用。

最后，如果实体不能从任何缓存中加载，它将被从数据库中加载。

现在，这个过程可以在调用 EntityManager.find ，在遍历一个关联时发生，也可以间接地用于 FetchType.EAGER 策略。

检查N+1查询问题

JPA关联获取验证器文章解释了如何以编程方式断言JPA关联获取。这个工具在测试过程中非常有用，但是对于那些要第一次检查生产系统的顾问来说就不太实用了。

例如，让我们举一个 Spring PetClinic 应用程序的例子。

@Entity@Table(name = "pets")public class Pet extends NamedEntity {    @Column(name = "birth_date")    @DateTimeFormat(pattern = "yyyy-MM-dd")    private LocalDate birthDate;    @ManyToOne    @JoinColumn(name = "type_id")    private PetType type;    @ManyToOne    @JoinColumn(name = "owner_id")    private Owner owner;    }复制代码

Pet 实体有两个父关联， type 和 owner ，每个都被注解为 @ManyToOne 。然而，默认情况下， @ManyToOne 关联使用 FetchType.EAGER 的获取策略。

因此，如果我们加载2个 Pet 实体，同时也获取它们相关的 owner 关联。

List pets = entityManager.createQuery("""    select p    from Pet p    join fetch p.owner    where p.id in :petIds    """).setParameter("petIds", List.of(3L, 6L)).getResultList();复制代码

Hibernate将执行3次查询。

SELECT     p.id as id1_1_1_,    p.name as name2_1_1_,     p.birth_date as birth_da3_1_1_,     p.owner_id as owner_id4_1_1_,     p.type_id as type_id5_1_1_,     o.id as id1_0_0_,     o.first_name as first_na2_0_0_,     o.last_name as last_nam3_0_0_,     o.address as address4_0_0_,     o.city as city5_0_0_,     o.telephone as telephon6_0_0_FROM     pets p JOIN     owners o ON o.id = p.owner_id WHERE     p.id IN (3, 6)SELECT     pt.id as id1_3_0_,     pt.name as name2_3_0_ FROM     types pt WHERE     pt.id = 3    SELECT     pt.id as id1_3_0_,     pt.name as name2_3_0_ FROM     types pt WHERE     pt.id = 6复制代码

那么，为什么会有3个查询被执行，而不是只有一个？这就是臭名昭著的N+1查询问题。

使用Lightrun进行Java性能调优

虽然你可以使用集成测试来检测N+1查询问题，但有时你不能这样做，因为你被雇来分析的系统已经部署到生产中，而你还没有看到源代码。

在这种情况下，像Lightrun这样的工具就变得非常方便，因为你可以简单地动态注入一个运行时快照，这个快照只有在满足特定条件时才会被记录。

第一步是在 DefaultLoadEventListener Hibernate类的 loadFromDatasource 方法中添加一个运行时快照。

注意，快照只记录相关的 LoadEvent 的 isAssociationFetch() 方法返回 true 。这个条件允许我们捕获N+1查询问题所执行的二次查询。

现在，当加载所有姓戴维斯的宠物主人时，PetClinic应用程序会执行以下SQL查询。

SELECT DISTINCT     o.id AS id1_0_0_,    p.id AS id1_1_1_,    o.first_name AS first_na2_0_0_,    o.last_name AS last_nam3_0_0_,    o.address AS address4_0_0_,    o.city AS city5_0_0_,    o.telephone AS telephon6_0_0_,    p.name AS name2_1_1_,    p.birth_date AS birth_da3_1_1_,    p.owner_id AS owner_id4_1_1_,    p.type_id AS type_id5_1_1_,    p.owner_id AS owner_id4_1_0__,    p.id AS id1_1_0__FROM     owners oLEFT OUTER JOIN     pets p ON o.id=p.owner_idWHERE     o.last_name LIKE 'Davis%'    SELECT     pt.id as id1_3_0_,     pt.name as name2_3_0_ FROM     types pt WHERE     pt.id = 6SELECT     pt.id as id1_3_0_,     pt.name as name2_3_0_ FROM     types pt WHERE     pt.id = 3复制代码

而在检查Lightrun快照控制台时，我们可以看到有两条记录被注册。

第一个快照看起来如下。

而第二个快照看起来是这样的。

请注意，由于大量使用了 FetchType.EAGER 策略，这两个快照对应于Spring Petclinic应用程序执行的二级查询。

很酷，对吗？