深入浅出 Java 虚拟机（八）分库分表导致的内存溢出

本文章为《深入浅出 Java 虚拟机》系列课程学习笔记，侵删。学习地址为 深入浅出 Java 虚拟机

从一个案例开始

我们现在有一个用户表，需要根据用户名查询用户，SQL 语句并不难：

select * from user where fullname = "xxx" and other="other";

在实际开发的过程中，经常需要动态拼接的效果，即当 fullname 或者 other 传入为空的时候，动态去掉这些查询条件（构建一个字符串 select * from user where 1=1，后面判断条件是否为空，不为空则添加，为空不添加），这种写法在大多数情况也是没有问题的，因为结果集合是可以控制的。但随着系统的运行，用户表的记录越来越多，当传入的 fullname 和 other 全部为空时，悲剧的事情发生了，SQL 被拼接成了如下的语句：

select * from user where 1=1

这会查询出数据库中的所有记录，并载入到 JVM 的内存中，过多的数据库记录容易导致内存被撑爆。

在实际工作中，这种情况引起的内存溢出频率非常高，为解决这个问题，我们可以选择强行加入分页功能，或者对一些必填的参数进行校验，但不总是有效。因为我们使用的示例仅展示了一个非常简单的 SQL 语句，而在实际工作中，这个 SQL 语句会非常长，每个条件对结果集的影响也会非常大，在进行数据筛选的时候，一定要小心。

内存使用问题

我们来看一下一个 Spring Boot 应用的分层，分析每一层可能出现的一些不正常的内存使用问题，以便对平常工作中的性能分析和性能优化有一个整体的思路。

Controller 层

Controller 层用于接收前端查询参数，然后构造查询结果。现在很多项目都采用前后端分离架构，所以 Controller 层的方法，一般使用 @ResponseBody 注解，把查询的结果，解析成 JSON 数据返回。

这在数据集非常大的情况下，会占用很多内存资源。假如结果集在解析成 JSON 之前，占用的内存是 10MB，那么在解析过程中，有可能会使用 20M 或者更多的内存去做这个工作。如果结果集有非常深的嵌套层次，或者引用了另外一个占用内存很大，且对于本次请求无意义的对象（比如非常大的 byte[] 对象），那这些序列化工具会让问题变得更加严重。

因此，对于一般的服务，保持结果集的精简，是非常有必要的，这也是 DTO（Data Transfer Object）存在的必要。如果你的项目，返回的结果结构比较复杂，对结果集进行一次转换是非常有必要的。互联网环境不怕小结果集的高并发请求，却非常恐惧大结果集的耗时请求，这是其中一方面的原因。

Service 层

Service 层用于处理具体的业务，更加贴合业务的功能需求，其主要问题是对底层资源的不合理使用。例如下面代码：

//错误代码示例
int getUserSize() {
    List<User> users = dao.getAllUser();
    return null == users ? 0 : users.size();
}

Service 层的另外一个问题就是，职责不清、代码混乱，以至于在发生故障的时候，让人无从下手，这种情况我们也应该尽量避免。

ORM 层

ORM 层可能是发生内存问题最多的地方，除了文章开始提到的 SQL 拼接问题，大多数是由于对这些 ORM 工具使用不当而引起的。

举个例子，在 JPA 中，如果加了一对多或者多对多的映射关系，而又没有开启懒加载、级联查询的时候就容易造成深层次的检索，内存的开销就超出了我们的期望，造成过度使用。

另外，JPA 可以通过使用缓存来减少 SQL 的查询，它默认开启了一级缓存，也就是 EntityManager 层的缓存（会话或事务缓存），如果你的事务非常的大，它会缓存很多不需要的数据；JPA 还可以通过一定的配置来完成二级缓存，也就是全局缓存，造成更多的内存占用。

一般，项目中用到缓存的地方，要特别小心。除了容易造成数据不一致之外，对堆内内存的使用也要格外关注。如果使用量过多，很容易造成频繁 GC，甚至内存溢出。

事实证明，不论是插入操作还是查询动作，只要涉及的数据集非常大，就容易出现问题。由于项目中众多框架的引入，想要分析这些具体的内存占用，就变得非常困难。保持小批量操作和结果集的干净，是一个非常好的习惯。

分库分表内存溢出

如果数据库的记录非常多，达到千万或者亿级别，对于一个传统的 RDBMS 来说，最通用的解决方式就是分库分表。这也是海量数据的互联网公司必须面临的一个问题。

分库分表有时会导致内存溢出，一个最典型的场景，就是在订单查询中使用了深分页，并且在查询的时候没有使用“切分键”。举个例子，订单数据被存放在两个库中。如果没有提供切分键，查询语句就会被分发到所有的数据库中，这里的查询语句是 limit 10、offset 1000，最终结果只需要返回 10 条记录，但是数据库中间件要完成这种计算，则需要 (1000+10)*2=2020 条记录来完成这个计算过程。如果 offset 的值过大，使用的内存就会暴涨。