使用Hibernate加载全表实体导致应用崩溃的解决方案

兄弟，一次性拉28万条数据进内存，这不崩才怪呢！我来给你唠几个实用的解决方案，从Hibernate自带的功能到逻辑优化都有，亲测有效：

核心思路就是把大结果集拆成小批次加载，避免一次性把所有对象塞进内存。Hibernate原生支持分页，用setFirstResult和setMaxResults就行：

Query<Item> query = session.createQuery("FROM Item WHERE isDeleted = false", Item.class);
int pageSize = 1000; // 可以根据内存情况调整，比如500或2000条一页
int currentPage = 0;
List<Item> pageItems;

do {
    query.setFirstResult(currentPage * pageSize);
    query.setMaxResults(pageSize);
    pageItems = query.list();
    
    // 这里写你处理当前页数据的逻辑，比如批量导出、统计分析等
    processPageData(pageItems);
    
    currentPage++;
} while (!pageItems.isEmpty());

不过要注意，当页码很大时，MySQL的LIMIT offset, rows会变慢（因为要扫描前面所有行）。这时候可以换键分页（用自增id或时间戳做游标），性能会好很多：

Long lastProcessedId = 0;
int batchSize = 1000;
List<Item> batchItems;

do {
    batchItems = session.createQuery(
            "FROM Item WHERE isDeleted = false AND id > :lastId ORDER BY id", 
            Item.class)
        .setParameter("lastId", lastProcessedId)
        .setMaxResults(batchSize)
        .list();
    
    if (!batchItems.isEmpty()) {
        lastProcessedId = batchItems.get(batchItems.size() - 1).getId();
        processPageData(batchItems);
    }
} while (!batchItems.isEmpty());

如果不想分页，或者需要逐行操作数据，Hibernate的ScrollableResults是个好东西——它不会一次性加载所有数据，而是像游标一样，用的时候才从数据库取：

Session session = sessionFactory.openSession();
Transaction tx = session.beginTransaction();

// 用FORWARD_ONLY模式，只向前滚动，性能最优
ScrollableResults results = session.createQuery("FROM Item WHERE isDeleted = false")
                                   .scroll(ScrollMode.FORWARD_ONLY);

int count = 0;
while (results.next()) {
    Item item = (Item) results.get(0);
    // 处理单个Item
    processSingleItem(item);
    
    // 每处理1000条就清空session缓存，避免内存溢出
    count++;
    if (count % 1000 == 0) {
        session.flush();
        session.clear();
    }
}

tx.commit();
session.close();

这里一定要记得用session.evict(item)或者批量clear()，不然session会把所有加载过的对象都存在缓存里，最后还是会爆内存。

• 只加载需要的字段：如果你的业务不需要Item的所有属性，别加载整个对象！用投影查询只拿必要的字段，或者用DTO接收：

// 用Object数组接收字段
List<Object[]> itemFields = session.createQuery(
        "SELECT id, name, price FROM Item WHERE isDeleted = false")
    .list();

// 或者用自定义DTO（需要有对应的构造方法）
List<ItemDTO> itemDTOs = session.createQuery(
        "SELECT new com.your.project.dto.ItemDTO(id, name, price) FROM Item WHERE isDeleted = false",
        ItemDTO.class)
    .list();

这样每个“数据单元”的内存占用会小很多，28万条也不会太夸张。

• 干掉N+1查询坑：如果Item关联了其他实体（比如Category），默认懒加载会导致处理数据时触发大量额外SQL，既慢又占内存。提前用JOIN FETCH加载关联对象：

Query<Item> query = session.createQuery(
        "FROM Item i JOIN FETCH i.category WHERE i.isDeleted = false",
        Item.class);

如果有重复数据，记得加DISTINCT去重。

• 异步/批量拆分任务：如果业务允许，把数据处理拆成异步任务，比如用Spring的@Async，或者扔到消息队列里分批次处理，不让主线程扛所有内存压力。

• 给查询字段加索引：给isDeleted和分页/排序用到的字段（比如id）加索引，让数据库更快找到数据，减少Hibernate的等待时间。
• 调整数据库缓存：比如增大MySQL的innodb_buffer_pool_size，让数据库缓存更多数据，减少磁盘IO，整体查询速度会提升不少（这个需要运维配合调整）。

总的来说，优先用分页或滚动结果集控制内存，再结合字段投影和N+1优化，基本就能解决崩溃问题了！

内容的提问来源于stack exchange，提问作者kibowki