在Java桌面程序或本地服务里，SQLite常被用来存放配置、用户信息、业务字典等数据。它的好处是部署简单，一个文件就是一个库，不需要单独安装数据库服务。但当界面列表频繁刷新或者多个线程同时读取时，每次都执行SQL查询会带来不必要的磁盘IO。Guava Cache正好可以作为SQLite前面的一层内存缓冲，把热点数据留在JVM堆内，命中率足够高时，大部分请求不会触达数据库。
一、为什么要把SQLite和Guava Cache放在一起用
SQLite在嵌入式场景中的优势非常明显，它不需要独立服务进程，所有数据都存放在单个文件中，SQL支持也比较完整。但它的读性能受限于文件系统，即使是同一个进程内的查询，也要经过SQL解析、锁管理、页面缓存和磁盘读取等步骤。如果一张表被频繁访问，而数据变化并不频繁，每次都直接查询SQLite会造成不必要的资源消耗，尤其是在UI线程中同步查询时，容易让界面出现卡顿。
Guava Cache是Google Guava库中提供的一个本地内存缓存实现，它可以直接嵌入JVM进程，不需要像Redis那样额外部署服务。它支持基于容量大小、写入时间、访问时间的过期策略，还提供了CacheLoader机制来定义自动加载逻辑。与手工使用ConcurrentHashMap相比，Guava Cache解决了缓存过期、并发加载、统计信息等通用问题，代码更少也更可靠。
两者配合后，SQLite负责持久化，Guava Cache负责热点数据的快速读取。读取路径由原来的每次直达磁盘，变成先查内存缓存，未命中时再回源SQLite并回填缓存。对于读多写少的数据，这种两级结构可以显著降低SQLite的查询压力，同时也保持了持久化层的数据可靠性。
二、核心设计：缓存键与回源加载
缓存键的设计直接影响命中率和维护成本。通常建议使用业务主键，或者由实体类型和ID组合成前缀形式，例如用户缓存的键可以写成user:1001，订单状态字典的键写成dict:ORDER_STATUS。如果键的粒度太粗，比如把整张表当作一个缓存项，一旦某一行更新就需要失效全部数据，抖动很大；如果粒度太细，比如每个字段单独缓存，又会造成大量的key和难以维护的回源逻辑。因此，以实体或逻辑分组为单位的缓存键是最常见的选择。
Guava Cache的CacheLoader接口可以定义回源加载逻辑。当调用get方法时，如果对应的键不存在，Guava会自动调用load方法，从SQLite查询数据并放入缓存。这样调用方不需要自己判断缓存是否命中，也不需要担心并发情况下同一个key被重复加载，因为Guava Cache内部会保证同一个key同时只会触发一次load。
回源查询时要注意避免返回null。Guava Cache默认不允许缓存null值，如果SQLite中确实没有对应记录，建议返回一个预定义的空对象，或者抛出业务异常。否则每次查询不存在的key都会触发load，造成缓存穿透，让后端数据库反复承受无效查询。
三、代码实现：封装数据访问层
下面给出一个简单的UserCacheService，它使用SQLite JDBC和Guava Cache完成用户数据的读写。这个类把缓存逻辑封装在getUserById和saveUser两个方法中，调用方只关心业务接口，不需要知道缓存和数据库的具体交互。User类是一个常见的POJO，其中预定义了一个EMPTY空对象用于表示用户不存在。
import com.google.common.cache.Cache;
import com.google.common.cache.CacheBuilder;
import java.sql.*;
import java.util.concurrent.TimeUnit;
public class UserCacheService {
private final Cache<String, User> cache;
private final String dbPath;
public UserCacheService(String dbPath) {
this.dbPath = dbPath;
this.cache = CacheBuilder.newBuilder()
.maximumSize(1000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.recordStats()
.build();
}
public User getUserById(String userId) throws Exception {
return cache.get("user:" + userId, () -> loadUserFromSqlite(userId));
}
private User loadUserFromSqlite(String userId) throws Exception {
String sql = "SELECT id, name, email FROM users WHERE id = ?";
try (Connection conn = DriverManager.getConnection("jdbc:sqlite:" + dbPath);
PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, userId);
try (ResultSet rs = ps.executeQuery()) {
if (rs.next()) {
User user = new User();
user.setId(rs.getString("id"));
user.setName(rs.getString("name"));
user.setEmail(rs.getString("email"));
return user;
}
return User.EMPTY;
}
}
}
public void saveUser(User user) throws Exception {
String sql = "INSERT OR REPLACE INTO users(id, name, email) VALUES(?, ?, ?)";
try (Connection conn = DriverManager.getConnection("jdbc:sqlite:" + dbPath);
PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setString(1, user.getId());
ps.setString(2, user.getName());
ps.setString(3, user.getEmail());
ps.executeUpdate();
}
cache.invalidate("user:" + user.getId());
}
public Cache<String, User> getCache() {
return cache;
}
}
代码中的CacheBuilder设置了最大容量1000条，超过后按照近似LRU策略淘汰，同时设置了写入后10分钟过期。recordStats会记录命中率、加载耗时等指标，方便后续调优。在getUserById方法里，lambda表达式作为加载函数传给get，如果没有命中缓存，就调用loadUserFromSqlite执行SQL查询。saveUser方法先写入SQLite，成功后对对应key调用invalidate，让缓存失效，下一次读取时再重新加载。
SQLite连接管理同样不能忽视。示例中使用了try-with-resources确保Connection、PreparedStatement和ResultSet都能及时关闭。SQLite JDBC驱动默认会创建文件锁，如果连接忘记关闭，可能导致后续写入操作失败或文件被锁住。对于高并发场景，可以考虑引入连接池，但SQLite本身写并发有限，一般建议把写操作串行化处理。
四、缓存失效与一致性处理
在saveUser方法中，写入SQLite成功后执行了cache.invalidate，这是一种简单有效的写后失效策略。与写后刷新相比，失效不会在写路径上增加额外的查询负担，适合写入频率不高的场景。如果写入和读取都非常频繁，并且读多写少不明显，可以选择在写入后直接调用cache.put更新缓存，减少下一次读取的回源开销，但需要处理并发写覆盖的问题。
当存在批量更新或者外部进程直接修改SQLite文件时，进程内的Guava Cache无法自动感知。必须通过TTL过期策略做兜底。示例中expireAfterWrite设置10分钟，意味着即使某个缓存项错过了手动失效，最多10分钟后也会被淘汰，重新查询SQLite。这样即使漏掉一次失效通知，也不会让脏数据永久存在。对于要求更高的场景，可以结合版本号或文件监听机制主动触发缓存清理。
缓存一致性在多线程环境下也需要留意。Guava Cache本身是线程安全的，get操作会保证同一个key并发加载时只触发一次load，避免缓存击穿。但save和get之间仍然存在竞态窗口。例如线程A正在读取旧缓存，线程B刚更新了SQLite，线程A可能返回旧值。如果业务无法接受这种短暂不一致，可以在更新数据库和缓存时使用同步块或数据库事务，并配合版本判断。
五、性能调优与常见坑
开启recordStats后，可以通过cache.stats()查看请求总数、命中次数、加载成功次数和平均加载时间。根据命中率调整缓存容量和过期时间。如果命中率长期低于预期，通常说明缓存键设计不合理，或者数据变化太快。此时可以尝试把缓存粒度细化，或者把更多读取入口纳入缓存路径。如果加载时间过长，说明SQLite查询本身需要优化，可以建立索引或减少返回字段。
实战中有几个常见坑需要注意。第一是缓存了可变的Java对象，外部代码修改对象属性后，缓存中的值也被改变，造成数据污染，解决方法是返回不可变对象或副本。第二是SQLite连接没有及时关闭，尤其是在异常分支中忘记释放资源，可能导致文件锁竞争。第三是忽略了Guava Cache不允许缓存null，导致不存在的数据频繁回源。第四是过期时间设置过短或过长，造成缓存命中率低或脏数据停留太久。第五是maximunSize设置过大会占用过多堆内存，需要结合对象大小估算合理容量。
对于读多写少的小型数据表，可以在应用启动时全量加载到Guava Cache中，后续读取完全走内存，SQLite只作为持久化备份。这种方案要求数据量可控，通常适合几千到几万条记录的字典表或配置表。如果数据量较大，可以只缓存最近访问的部分记录，通过maximumSize限制缓存总量，让冷数据自动淘汰。预加载可以提升启动后的首次访问体验，避免冷启动时集中回源造成压力。
SQLiteGuava Cache本地缓存修改时间：2026-09-20 03:08:12