Java：异步数据库写入的TaskExecutor？
我正在考虑使用Java的TaskExecutor来启动异步数据库写入。 可以理解的是，线程并不是免费的，但假设我使用的固定线程池大小为5-10，这怎么是一个坏主意？
我们的应用程序使用缓冲区从一个非常大的文件读取，并在执行一些数据操作后将此信息刷新到数据库。 在这里使用异步写入似乎是理想的，这样我们就可以继续处理该文件了。 我错过了什么？ 为什么每个应用程序都不使用异步写入？
为什么每个应用程序都不使用异步写入？
以同步方式处理写入失败通常是必要/有用/更容易的。
我不确定线程池是否必要。 我会考虑使用专用的databaseWriter线程，它为您完成所有写入和error handling。 就像是：
public class AsyncDatabaseWriter implements Runnable { private LinkedBlockingQueue queue = .... private volatile boolean terminate = false; public void run() { while(!terminate) { Data data = queue.take(); // write to database } } public void ScheduleWrite(Data data) { queue.add(data); } } 我个人喜欢使用Proxy来处理可能需要很长时间的操作的风格。 我并不是说这种方法比以任何方式使用执行程序更好，只是将其添加为替代方法。
想法一点都不差。 实际上我昨天只是尝试了，因为我需要创建一个在线数据库的副本，它有5个不同的类别，每个类别有60000个项目。
通过将每个类别的解析/保存操作移动到并行任务中并将每个类别导入分区为并行运行的较小批次，我将总导入时间从几个小时（估计）减少到26分钟。 在此过程中，我找到了用于拆分集合的优秀代码： http ： //www.vogella.de/articles/JavaAlgorithmsPartitionCollection/article.html
我使用ThreadPoolTaskExecutor来运行任务。 您的任务只是Callable接口的简单实现。
为什么每个应用程序都不使用异步写入？ – 因为每个应用程序都做了不同的事情。
你能相信一些应用程序甚至不使用数据库OMG !!!!!!!!!
严肃地说，因为你没有说出你的失败策略是什么 – 听起来这可能是合理的。 如果写入失败会发生什么？ 或者数据库以某种方式消失了
一些数据库 – 比如sybase – 已经（或者至少有）他们真的不喜欢单个表的多个编写者 – 所有的编写者最终都互相阻塞 – 所以也许它实际上并没有太大的区别……