当前位置：首页 > news >正文

详细介绍：性能优化 - 案例篇：缓存_Guava#LoadingCache设计

news 2025/10/5 10:35:26

详细介绍：性能优化 - 案例篇：缓存_Guava#LoadingCache设计

Pre

性能优化 - 理论篇：常见指标及切入点

性能优化 - 理论篇：性能优化的七类技术手段

性能优化 - 理论篇：CPU、内存、I/O诊断手段

性能优化 - 工具篇：常用的性能测试工具

性能优化 - 工具篇：基准测试 JMH

性能优化 - 案例篇：缓冲区

引言：解释缓存与缓冲的区别及缓存在性能优化中的重要性；
缓存基本概念：缓存的本质、应用场景、进程内 vs 进程外缓存；
Guava LoadingCache（LC）示例：
3.1 引入依赖与初始化配置；
3.2 手动 put 与自动加载（CacheLoader）模式；
3.3 缓存容量、初始大小与并发级别设置；
3.4 缓存移除与监听（invalidate + removalListener）；
缓存回收策略：
4.1 基于容量的回收（LRU）；
4.2 基于时间的回收（expireAfterWrite / expireAfterAccess）；
4.3 基于 JVM GC 的回收（weakKeys / weakValues / softValues）；
4.4 GC 回收引发的缓存颠簸问题与解决思路；
缓存算法简述：FIFO、LRU、LFU 三种常见策略；
用 LinkedHashMap 实现简易 LRU：
6.1 LinkedHashMap 构造参数与访问顺序；
6.2 覆盖 removeEldestEntry 实现容量控制；
6.3 线程安全与功能局限性说明；
操作系统层面的预读与文件缓存：readahead 机制、完全加载策略；
缓存优化一般思路：何时用缓存、容量与命中率考量；
缓存的一些注意事项与示例：HTTP 304、CDN；

引言

在性能优化 - 案例篇：缓冲区中，介绍了“缓冲”这一优化手段——通过将数据暂存到内存缓冲区，批量顺序读写来缓解设备间的速度差异。与缓冲相伴随的“孪生兄弟”就是缓存（Cache）。缓存将常用数据放到相对高速的存储层（如内存）中，从而在后续访问时实现瞬时读取，显著提升性能。

举例而言：

浏览热门页面时，只要缓存中已有渲染结果，就可以实现“秒开”；
对数据库而言，引入缓存后，频繁查询热点记录可以直接命中缓存，数据库几乎无需负载。

缓存几乎是软件中最常见的优化技术。从 CPU L1/L2/L3 缓存到 Redis、Memcached 这样的分布式缓存，无不围绕“速度差异协调”这一核心展开。

接下来我们主要聚焦于进程内缓存——堆内缓存，以 Guava 的 LoadingCache 为示例讲解堆内缓存设计思路、常见回收策略和算法实现。

1. 缓存基本概念

缓存的核心作用，是在两个速度差异巨大的组件之间增加一层高速存储：

速度慢组件：如数据库、文件存储，访问一次可能耗费几毫秒或更长；
速度快组件：如 CPU 寄存器、内存读写，只需几十纳秒；
缓存层（中间层）：通常部署在内存中，通过哈希映射、LRU 回收等策略，只要缓存命中就能以几百纳秒返回结果。

根据缓存所在的物理位置，可将其分为：

进程内缓存（堆内缓存）：直接存放在 JVM 堆里，访问速度最快，但容量受限于可用堆内存；
进程外缓存（进程间或分布式缓存）：如 Redis、Memcached，通常运行在独立进程或集群里，通过网络访问，虽然速度比数据库快许多，但仍比堆内缓存慢一个数量级；

接下来重点讲解 进程内缓存，常见实现包括 Guava Cache、Caffeine、Ehcache、JCache 等。它们都提供了基于内存分片、高并发访问、灵活回收策略和统计监控的堆内缓存解决方案。

2. Guava 的 LoadingCache

Guava 提供了功能强大的 Cache 接口和 LoadingCache 实现，既支持手动存入（put()），也支持在缓存未命中时“自动加载”（CacheLoader）。下面通过示例逐步介绍其用法与内部配置要点。

2.1 引入依赖与初始化

首先，通过 Maven 将 Guava 库加入项目：

<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>29.0-jre</version>
</dependency>

然后，使用 CacheBuilder 来创建一个 LoadingCache：

LoadingCache<
String
, String> lc = CacheBuilder
.newBuilder(
)
// 设置最大缓存容量：达到上限后回收其他元素
.maximumSize(1000
)
// 设置初始容量：底层 Hash 表的初始大小为 16（默认）
.initialCapacity(16
)
// 设置并发级别：将缓存分片成 4 个 segment，提升并发读写性能
.concurrencyLevel(4
)
.build(
new CacheLoader<
String
, String>(
) {
@Override
public String load(String key)
throws Exception {
// 缓存未命中时，自动调用 slowMethod 从外部数据源加载
return slowMethod(key)
;
}
}
)
;

maximumSize(int)：指定 缓存中可保留条目的最大数量，一旦超过，将根据回收策略（默认 LRU）移除旧元素；
initialCapacity(int)：指定底层哈希表初始大小（bucket 数量），避免在缓存初始化时反复扩容；
concurrencyLevel(int)：指定并发写的“分段”数，Guava 会将内部数据结构拆分为 concurrencyLevel 个部分，以减少并发冲突；

2.2 手动 put 与自动加载（CacheLoader）

LoadingCache 支持两种获取方式：

手动 put()：

lc.put("key1"
, "value1"
)
;
String v = lc.getIfPresent("key1"
)
;
// 立即返回 "value1"

在这种模式下，开发者负责将外部数据同步写入缓存。

自动加载 get()：

// 第一次调用：缓存中无 key "a"，触发 CacheLoader.load("a")
long start = System.nanoTime(
)
;
String result1 = lc.get("a"
)
;
// slowMethod("a") 需 1s
System.out.println("第一次调用耗时: " + (System.nanoTime(
) - start)
)
;
// 第二次调用：缓存命中，迅速返回
long start2 = System.nanoTime(
)
;
String result2 = lc.get("a"
)
;
System.out.println("第二次调用耗时: " + (System.nanoTime(
) - start2)
)
;

其中 load(String key) 方法可同步加载所需数据（如从数据库或外部 API 拉取），并在返回值后自动存入缓存。

2.2.1 示例代码

public
class GuavaCacheDemo {
// 模拟一个缓慢方法：睡眠 1 秒后返回结果
static String slowMethod(String key)
throws Exception {
Thread.sleep(1000
)
;
return key + ".result"
;
}
public
static
void main(String[] args)
throws Exception {
LoadingCache<
String
, String> lc = CacheBuilder
.newBuilder(
)
.maximumSize(1000
)
.initialCapacity(16
)
.concurrencyLevel(4
)
.recordStats(
) // 开启统计信息收集
.build(
new CacheLoader<
String
, String>(
) {
@Override
public String load(String key)
throws Exception {
return slowMethod(key)
;
}
}
)
;
// 第一次 get，会调用 slowMethod
long t1 = System.nanoTime(
)
;
String v1 = lc.get("a"
)
;
long elapsed1 = System.nanoTime(
) - t1;
System.out.println("第一次 get 用时: " + elapsed1 + " ns"
)
;
// 第二次 get，立即返回
long t2 = System.nanoTime(
)
;
String v2 = lc.get("a"
)
;
long elapsed2 = System.nanoTime(
) - t2;
System.out.println("第二次 get 用时: " + elapsed2 + " ns"
)
;
// 输出命中率与加载次数等统计
System.out.println("Cache Stats: " + lc.stats(
)
)
;
}
}

recordStats()：开启缓存统计功能，可用于后续分析 hitRate()、loadSuccessCount() 等指标；
CacheLoader.load()：当 key 未命中时，自动调用并将结果写回缓存；

2.3 缓存移除与监听（invalidate + removalListener）

手动删除：

lc.invalidate("a"
)
;
// 移除 key "a" 对应的缓存项

监听删除事件：

LoadingCache<
String
, String> lc2 = CacheBuilder.newBuilder(
)
.removalListener(notification ->
{
System.out.println("移除: " + notification.getKey(
)
+ " 因为 " + notification.getCause(
)
)
;
}
)
.maximumSize(100
)
.build(
new CacheLoader<
>(
) {
@Override
public String load(String key) {
return slowMethod(key)
;
}
}
)
;

当缓存项因为容量、过期、显式 invalidate() 等原因被移除时，监听器会收到回调，可用于日志、监控或二次清理。

3. 缓存回收策略

在缓存容量有限的前提下，需设计合适的回收策略来剔除“冷”或不再需要的数据，以保证“热点”数据得到优先保留。Guava 原生支持多种回收方式：

Cache<
String
,
byte[]> cache = CacheBuilder.newBuilder(
)
.maximumSize(1000
)
.weakValues(
)
.build(
)
;

面试高频：若同时设置 weakKeys() 与 weakValues()，则当 key 或 value 都失去任何强引用后，该条目会被 GC 回收。

3.3.1 GC 回收引发的缓存颠簸问题

当缓存条目使用弱引用或软引用，一旦 JVM 触发 GC，就可能一次性清空大批缓存数据。若该缓存频繁被访问，缓存将被迅速重新加载，导致连续触发多次 GC 和缓存“哗啦啦回补”的现象——CPU 消耗骤增，却无法留住数据。

解决思路：

仅对内存占用较大的非热点对象使用 softValues()，而不是对所有缓存。一旦发现缓存颠簸，可考虑放宽 GC 压力或降低缓存容量；
尽量使用基于容量+时间的回收，避免过度依赖 JVM GC；
在缓存加载逻辑中加入适当延迟，防止短时间内同一批 key 被重复加载。

4. 常见缓存算法简介

除了 Guava 提供的默认 LRU，缓存领域常见还有两种算法：

4.1 FIFO（先进先出）

按“插入顺序”回收：

4.2 LRU（最近最少使用）

按“访问顺序”回收：

4.3 LFU（最近最不常用）

按“访问频率”回收：

5. 简易 LRU 实现——LinkedHashMap

在 Java 中，要实现一个轻量级的 LRU 缓存，最便捷的方式是利用 LinkedHashMap 提供的“访问顺序”功能：

public
class LRUCache<
K
, V>
extends LinkedHashMap<
K
, V> {
private
final
int capacity;
public LRUCache(
int capacity) {
// 初始容量 16，负载因子 0.75，accessOrder=true 表示按访问顺序排列
super(16
, 0.75f
, true
)
;
this.capacity = capacity;
}
// 当 put 后，自动调用此方法判断是否需要移除最老条目
@Override
protected
boolean removeEldestEntry(Map.Entry<
K
, V> eldest) {
return size(
) > capacity;
}
}

构造参数说明：
- initialCapacity：初始哈希表桶数，默认 16；
- loadFactor：负载因子（0.75f）；
- accessOrder=true：按照“访问顺序”保持双向链表；
removeEldestEntry：在每次 put() 后自动调用，若返回 true，则移除“最久未访问”者，即 LRU 算法的核心。

5.1 功能局限与线程安全

优势：代码简洁，无需自行维护优先级队列或计数器；
局限：
1. 仅基于“条目数量”控制容量，不能指定基于“内存占用大小”回收；
2. 无法设置“基于时间过期”或“基于访问次数”回收；
线程安全：LinkedHashMap 本身并非线程安全，如需并发访问，应加锁或改用 ConcurrentLinkedHashMap / Guava Cache / Caffeine。

6. 操作系统层面的预读与文件缓存

在操作系统层面，对文件 I/O 缓存设计也非常智能，进一步支撑了高性能缓存架构。Linux 下可以通过 free 命令查看内存状态，其中 cached 区域往往十分庞大：

$ free -h
total        used        free      shared  buff/cache   available
Mem:           16Gi       4.2Gi       2.5Gi       128Mi       9.4Gi       11Gi
Swap:         2.0Gi       512Mi       1.5Gi