java分批同步数据oom_记一次刷数据遇到的坑-OOM问题

问题背景

笔者在处理一项刷数据的工作，过程是将数据源A的数据经过一些调整和计算后存入到数据源B，整个过程大致如下图所示。

过程概述

整个刷数据过程分为以下步骤：

通过执行SQL的join语句查询指定的数据(select A1.col1,A1.col2,A2.col3 from A1 join A2 on A1.col1=A2.col1 where userid=10086 > temp.out)

此时temp.out中的文件格式形如col1 \t col2 \t col3

通过在client端执行RPC调用(如dubbo)请求server端已有的添加接口将数据写入到表B

这么做是因为表B数据的写入伴随着相关的业务逻辑(例如操作记录、消息通知等)，因此需要复用server端已有的接口，步骤二client端的伪代码如下:

def transfer():

uid2Data = {}

for file in directory.listFiles(): # directory中有622个文件，共2.1G

uid = resolveUid(file)

uid2Data[uid] = resolveData(file) # 平均每个file中有30w行数据

for uid,data in uid2Data.items():

requestServer(uid, data) # 请求server

过程中出现的问题

-server -Xms16384m -Xmx32768m

在执行步骤二的时候首先是出现了java.lang.OutOfMemoryError: Java heap space错误，错误的原因很明显是JVM堆空间不足，这时统计了下文件系统中数据的量级已经达到了2.1G，从client端的伪代码实现也可以看出，是uid2Data这个Map太大了，在装载这个Map的时候出现了堆内存不足。

内存不足

由于client端代码改造成本较大，笔者开始从JVM调参入手考虑，既然堆内存不足，就调大堆内存为-server -Xms16384m -Xmx32768m

-server，既然刷数据任务比较漫长，则使用server模式运行重量级虚拟机来对运行时内存进行更多优化

JVM有两种运行模式Server与Client。两种模式的区别在于，Client模式启动速度较快，Server模式启动较慢；但是启动进入稳定期长期运行之后Server模式的程序运行速度比Client要快很多。这是因为Server模式启动的JVM采用的是重量级的虚拟机，对程序采用了更多的优化；而Client模式启动的JVM采用的是轻量级的虚拟机。所以Server启动慢，但稳定后速度比Client远远要快。

-Xms,-Xmx，设置JVM初始内存和最大内存

由此，遇到了我们第一个坑，The specified size exceeds the maximum representable size

Error: Could not create the Java Virtual Machine.

Error: A fatal exception has occurred. Program will exit.

Invalid initial heap size: -Xms8192m

The specified size exceeds the maximum representable size.

一脸懵逼

OutOfMemoryError，简称OOM，是Java开发中常见的错误，OOM是一种Error，区别于Exception(例如NPE，NullPointerException)，Error一般是虚拟机相关的问题，如系统崩溃、内存空间不足、方法调用栈溢出等，应用程序本身无法处理Error类错误，这种情况下建议让程序终止

OutOfMemoryError与FullGC的关系，FullGC通常发生在JVM老年代空间不足，概括理解为JVM不得不停下手上的工作清理屋子的垃圾，JVM区分垃圾的方式一般是通过GCRoot的强引用，如果一个对象没有到GCRoot的强引用，则判定为垃圾并进行回收。反之，如果一个对象有到GCRoot的强引用(存活)，则不论内存多么不足都坚决不回收，这么做的结果就可能会导致OOM。也就是说，发生了OOM可以理解为就是内存不足，而FullGC关注的点是运行太慢。

32bit vs. 64bit(jdk与操作系统)

经过一番排查后，发现报错的原因是申请的堆空间超过了最大寻址空间，但是我们的操作系统是windows10 64bit，排查发现是使用了32位的JDK，导致申请的空间不足。

于是笔者调低了申请的堆空间大小为4G，因为32位操作系统的寻址范围是2^32次方，不论实际内存空间有多少，操作系统都会给每个进程分配独立的4GB内存空间(虚拟内存+页表)，这样总没问题了吧，当笔者正因为自己操作系统的知识而沾沾自喜时，同样的报错还是发生了。

得意

经过一系列搜索+分析，才发现操作系统给每个进程分配的空间是用户空间+内核空间，所以其实在windows中JVM最大可用内存为1.5G，但是1.5G运行过后还是提示OOM，笔者只好放弃32位JDK，选择下载64位JDK，调大JVM堆空间再运行后程序正常执行。

反思

调整代码逻辑

想必很多读者已经发现了，“你兜兜转转搞了这么多不就是因为上面那段代码写的太烂了吗？”，确实，所以这也是后面相关刷数据操作需要牢记的原则，一定要合理评估操作的数据量并且依据数据量评估实现方案，很多时候会遇到这样测试时稳得一批的代码，在实际操作大量数据的时候血崩的情况。

代码应该调整为如下

def transfer():

for file in directory.listFiles(): # directory中有622个文件，共2.1G

uid = resolveUid(file)

data = resolveData(file) # 平均每个file中有30w行数据

requestServer(uid, data) # 每个文件内容单独请求一次server

Map-Reduce的思想

当处理的数据量大到一定程度时，就会很自然的想到将数据分开并发去请求，因为RPC服务的server往往是多台服务器，可以将622个文件的每次请求都改为并行请求server的一个线程，在执行后分别收集每个线程的执行结果并汇总。

client-多server

这个思想其实比较类似于Map-Reduce[1]的思想了，并发请求不同server的过程就是map的过程，收集每个线程的结果并汇总的过程其实就是reduce的过程。

如果存储在文件系统中的数据很大，大到单机的磁盘不足，就需要放到HDFS下，client脚本也需要去不同HDFS机器上取数并运算，请求的结果进行汇总时也需要reduce机器进行合并汇总。

扩展阅读