问题描述：
我们有一个任务是编写一个Java程序，它连接数据库，执行SQL查询，迭代包含数百万条记录的JDBC Resultset，并将数据写入平面文件。
建议的解决方案：
我想到了在Java中设计基于多线程的解决方案。
线程1：我有一个线程，其唯一的任务是迭代Resultset，获取每条记录，为每条记录创建一个DTO对象，将该DTO对象放到 java上。 util.concurrent.ConcurrentLinkedQueue
线程2：此线程仅用于从队列中提取每个DTO对象并将其写入Flat文件。
约束：我们不应该使用除Java之外的其他API
您觉得这种方法需要改进吗？或者有没有比这更好的方法，通过这种方法可以提高性能，因此，将数百万条记录导出到文件所需的时间非常短？
感谢您的时间。
答案 0 :(得分：0)
您可能需要一个BlockingQueue，以便编写器线程等待队列为空的元素。如果作者比读者慢得多，你也会有有限的背压选择。 BlockingQueue可以限制为某种大小，并强制读取器线程在添加到队列之前等待。还要考虑批量阅读。尝试测试不同的方法。
答案 1 :(得分：0)
当我需要回答是否应该使用多线程（MT）时，我遵循一般规则。规则是：以单线程模式运行程序并在taskmanager中查看cpu使用情况。如果cpu带处于恒定的25％或恒定的50％，则很可能有更多的螺纹可以提供帮助。 i5机器上的百分比实际为100/(no of cores)，因此为25％。
即使 这种情况，MT也可能没用，例如，如果您的任务无法有效并行化。这是一种体验和判断的事情。所以实施MT和测试。如果cpu使用率增加那么好，否则还原你的MT代码。
即使没有这种情况，也有更多线程帮助的情况。示例是必须等待webservice调用的gui代码。或者当你需要实现某种超时逻辑时。
在几乎所有情况下，改进都是减少和/或增加的代码复杂性不值得获得。请注意，做MT会导致难以捕获错误的方法。所以，即使MT看起来更酷酷，我还是专业地坚持任务管理器（抱歉，但我只是说了）。避免MT，除非它提供显着的性能提升。请记住，编写代码很容易。对于测试人员和错误修正者来说，最难的部分就在于它。