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

DebugUsery
365 阅读4分钟

简介

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

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

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

DefaultLoadEventListener

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

Fetching Entity First-Level Cache

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

这意味着，两个连续的实体获取调用将总是返回相同的JavaObject 引用。这就是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<Pet> 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 方法中添加一个运行时快照。

Lightrun DefaultLoadEventListener snapshot

注意，快照只记录相关的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 o
LEFT OUTER JOIN 
    pets p ON o.id=p.owner_id
WHERE 
    o.last_name LIKE 'Davis%'
    
SELECT 
    pt.id as id1_3_0_, 
    pt.name as name2_3_0_ 
FROM 
    types pt 
WHERE 
    pt.id = 6

SELECT 
    pt.id as id1_3_0_, 
    pt.name as name2_3_0_ 
FROM 
    types pt 
WHERE 
    pt.id = 3

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

第一个快照看起来如下。

Lightrun DefaultLoadEventListener first result

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

Lightrun DefaultLoadEventListener second result

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

很酷，对吗？

结论

虽然你可以在测试过程中使用JPA关联获取验证器来检测这些N+1查询问题，但如果你的任务是分析一个你从未见过的运行时系统，那么Lightrun就是一个发现各种问题及其发生原因的伟大工具。

特别是因为Java性能调优是我被雇用的最常见的原因之一，Lightrun是我的工具集的一个很好的补充。

avatar
文章
阅读
粉丝