Spring Boot 中的性能调优主要围绕数据库边界：连接池、缓存，以及消灭 N+1 查询问题。先测量（Micrometer + Actuator 指标），再攻击最大的成本项。
懒加载关联会对每个 parent 发一次查询，然后每次访问 child 时再发一次：
List<Order> orders = orderRepo.findAll(); // 1 次查询
for (Order o : orders) {
o.getItems().size(); // N 次额外查询——每个 order 一次（即"N+1"）
}
用单次 join 一次性取回关联来修复它：
@Query("SELECT o FROM Order o JOIN FETCH o.items") // 一次查询，items 急切加载
List<Order> findAllWithItems();
// 或在仓库方法上用 @EntityGraph(attributePaths = "items")。
HikariCP 是默认连接池。更大并非更好——连接过多会拖垮数据库。一个常见的公式从接近 cores * 2 起步：
spring:
datasource:
hikari:
maximum-pool-size: 10 # 匹配 DB 容量，而非线程数
connection-timeout: 3000 # 快速失败，而不是让请求堆积
@Cacheable(value = "products", key = "#id") // 首次加载后从缓存提供
public Product findById(Long id) { return repo.findById(id).orElseThrow(); }
@CacheEvict(value = "products", key = "#p.id") // 写入时失效
public Product update(Product p) { return repo.save(p); }
用 Redis（spring-boot-starter-data-redis）作为后端，以在多个实例间共享缓存。
高级面试考察你是否先诊断再优化。最强的答案会点名那个能证明瓶颈的工具（启用 spring.jpa.show-sql 或 datasource-proxy 来统计查询数，从 Actuator 读取 p99 延迟）、解释为什么过大的连接池有害，并把缓存当作一个正确性问题——过期数据与失效——而不只是一个提速旋钮。
一个包含详细解答的 IT 面试题库——从初级到高级。
捐赠