使用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应用程序执行的二级查询。
　　很酷，对吗？  结论
　　虽然你可以在测试过程中使用JPA关联获取验证器来检测这些N+1查询问题，但如果你的任务是分析一个你从未见过的运行时系统，那么Lightrun就是一个发现各种问题及其发生原因的伟大工具。
　　特别是因为Java性能调优是我被雇用的最常见的原因之一，Lightrun是我的工具集的一个很好的补充。