30G上亿数据的超大文件，如何快速导入生产环境？（Java）

这里之所以选择先将大文件拆分，主要考虑到两个原因：

第一如果程序直接读取这个大文件，假设读取一半的时候，程序突然宕机，这样就会直接丢失文件读取的进度，又需要重新开头读取。

而文件拆分之后，一旦小文件读取结束，我们可以将小文件移动一个指定文件夹。

这样即使应用程序宕机重启，我们重新读取时，只需要读取剩余的文件。

第二，一个文件，只能被一个应用程序读取，这样就限制了导入的速度。

而文件拆分之后，我们可以采用多节点部署的方式，水平扩展。每个节点读取一部分文件，这样就可以成倍的加快导入速度。

多线程导入

当我们拆分完文件，接着我们就需要读取文件内容，进行导入。

之前拆分的时候，设置每个小文件包含 10w 行的数据。由于担心一下子将 10w 数据读取应用中，导致堆内存占用过高，引起频繁的 Full GC，所以下面采用流式读取的方式，一行一行的读取数据。

当然了，如果拆分之后文件很小，或者说应用的堆内存设置很大，我们可以直接将文件加载到应用内存中处理。这样相对来说简单一点。

逐行读取的代码如下：

File file = …
try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), “UTF-8”)) {
while (iterator.hasNext()) {
String line=iterator.nextLine();
convertToDB(line);
}

}

上面代码使用 commons-io 中的 LineIterator类，这个类底层使用了 BufferedReader 读取文件内容。它将其封装成迭代器模式，这样我们可以很方便的迭代读取。

如果当前使用 JDK1.8 ，那么上述操作更加简单，我们可以直接使用 JDK 原生的类 Files将文件转成 Stream 方式读取，代码如下：

Files.lines(Paths.get(“文件路径”), Charset.defaultCharset()).forEach(line -> {
convertToDB(line);
});

其实仔细看下 Files#lines底层源码，其实原理跟上面的 LineIterator类似，同样也是封装成迭代器模式。

多线程的引入存在的问题

上述读取的代码写起来不难，但是存在效率问题，主要是因为只有单线程在导入，上一行数据导入完成之后，才能继续操作下一行。

为了加快导入速度，那我们就多来几个线程，并发导入。

多线程我们自然将会使用线程池的方式，相关代码改造如下：

File file = …;
ExecutorService executorService = new ThreadPoolExecutor(
5,
10,
60,
TimeUnit.MINUTES,
// 文件数量，假设文件包含 10W 行
new ArrayBlockingQueue<>(10*10000),
// guava 提供
new ThreadFactoryBuilder().setNameFormat(“test-%d”).build());
try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), “UTF-8”)) {
while (iterator.hasNext()) {
String line = iterator.nextLine();
executorService.submit(() -> {
convertToDB(line);
});
}

}

上述代码中，每读取到一行内容，就会直接交给线程池来执行。

我们知道线程池原理如下：

1. 如果核心线程数未满，将会直接创建线程执行任务。
2. 如果核心线程数已满，将会把任务放入到队列中。
3. 如果队列已满，将会再创建线程执行任务。
4. 如果最大线程数已满，队列也已满，那么将会执行拒绝策略。

由于我们上述线程池设置的核心线程数为 5，很快就到达了最大核心线程数，后续任务只能被加入队列。

为了后续任务不被线程池拒绝，我们可以采用如下方案：

• 将队列容量设置成很大，包含整个文件所有行数
• 将最大线程数设置成很大，数量大于件所有行数

以上两种方案都存在同样的问题，第一种是相当于将文件所有内容加载到内存，将会占用过多内存。

而第二种创建过多的线程，同样也会占用过多内存。

一旦内存占用过多，GC 无法清理，就可能会引起频繁的 Full GC，甚至导致 OOM，导致程序导入速度过慢。

解决这个问题，我们可以如下两种解决方案：

• CountDownLatch 批量执行
• 扩展线程池

CountDownLatch 批量执行

JDK 提供的 CountDownLatch，可以让主线程等待子线程都执行完成之后，再继续往下执行。

利用这个特性，我们可以改造多线程导入的代码,主体逻辑如下：

try (LineIterator iterator = IOUtils.lineIterator(new FileInputStream(file), “UTF-8”)) {
// 存储每个任务执行的行数
List lines = Lists.newArrayList();
// 存储异步任务
List tasks = Lists.newArrayList();
while (iterator.hasNext()) {
String line = iterator.nextLine();
lines.add(line);
// 设置每个线程执行的行数
if (lines.size() == 1000) {
// 新建异步任务，注意这里需要创建一个 List
tasks.add(new ConvertTask(Lists.newArrayList(lines)));
lines.clear();
}
if (tasks.size() == 10) {
asyncBatchExecuteTask(tasks);
}

}
// 文件读取结束，但是可能还存在未被内容
tasks.add(new ConvertTask(Lists.newArrayList(lines)));
// 最后再执行一次
asyncBatchExecuteTask(tasks);
}

这段代码中，每个异步任务将会导入 1000 行数据，等积累了 10 个异步任务，然后将会调用 asyncBatchExecuteTask 使用线程池异步执行。

/**

• 批量执行任务
• @param tasks
  */
  private static void asyncBatchExecuteTask(List tasks) throws InterruptedException {
  CountDownLatch countDownLatch = new CountDownLatch(tasks.size());
  for (ConvertTask task : tasks) {
  task.setCountDownLatch(countDownLatch);
  executorService.submit(task);
  }
  // 主线程等待异步线程 countDownLatch 执行结束
  countDownLatch.await();
  // 清空，重新添加任务
  tasks.clear();
  }

asyncBatchExecuteTask 方法内将会创建 CountDownLatch，然后主线程内调用 await方法等待所有异步线程执行结束。

ConvertTask 异步任务逻辑如下：

/**

• 异步任务
• 等数据导入完成之后，一定要调用 countDownLatch.countDown()
• 不然，这个主线程将会被阻塞，
  */
  private static class ConvertTask implements Runnable {

private CountDownLatch countDownLatch;

private List lines;

public ConvertTask(List lines) {
this.lines = lines;
}

public void setCountDownLatch(CountDownLatch countDownLatch) {
this.countDownLatch = countDownLatch;
}

@Override
public void run() {
try {
for (String line : lines) {

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

try {
for (String line : lines) {

最后总结

搞定算法，面试字节再不怕，有需要文章中分享的这些二叉树、链表、字符串、栈和队列等等各大面试高频知识点及解析

最后再分享一份终极手撕架构的大礼包(学习笔记)：分布式+微服务+开源框架+性能优化

[外链图片转存中…(img-BDy0kzns-1714250270973)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录