java线程中的task_java – 将FlatFileItemReader与TaskExecutor一起使用(线程安全)

有很多例子使用FlatFileItemReader和TaskExecutor.我在下面提供了示例(包括XML和Java Config)：

我已经将自己的XML配置用于大型CSV(GB大小),使用开箱即用的JpaItemWriter写入数据库.即使没有设置save-state = false或采取任何特殊处理,似乎也没有问题.

现在,FlatFileItemReader被记录为不是线程安全的.

我的猜测是,如果hashCode()和equals()覆盖了实体的业务密钥,JpaItemWriter通过持久化集合,即没有重复的集合来“覆盖”该问题.但是,即使这样,由于非线程安全的读取和处理,也不足以防止重复.

您能否澄清一下：在已分配TaskExecutor的Tasklet中使用开箱即用的FlatFileItemReader是否正确/正确/安全？无论作家如何.如果没有,我们怎么能在理论上解释使用JPAItemWriter时缺少错误？

P.S：我在上面给出的示例链接,使用FlatFileItemReader和TaskExecutor,但没有提到所有可能的线程安全问题……

解决方法:

TL; DR如果Writer是线程安全的,那么使用带有TaskExecutor的FlatFileItemReader是安全的. (假设您不关心重启作业,重试步骤,跳过等等).

更新：现在有一个JIRA正式确认saveState需要设置为false(即禁用可重启性),如果想要以线程安全方式使用FlatFileItemReader和TaskExecutor.

让我们首先通过查看Spring documentation关于使用TaskExecutor使用多线程步骤的内容来从马口听到它.

Spring Batch provides some implementations of ItemWriter and

ItemReader. Usually they say in the Javadocs if they are thread safe

or not, or what you have to do to avoid problems in a concurrent

environment. If there is no information in Javadocs, you can check the

implementation to see if there is any state

我们现在解决您的问题：

Could you please clarify: is it proper/correct/safe to use the

out-of-the-box FlatFileItemReader within a Tasklet which has assigned

a TaskExecutor? Regardless of the Writer. If not, how could we explain

in theory the lack of errors when a JPAItemWriter is used?

声明“作家的Regardess”是不正确的.您使用的Writer必须是线程安全的. JpaItemWriter是针对Java文档的线程安全的,可以安全地与不是线程安全的FlatFileItemReader一起使用.解释JpaItemWriter如何是线程安全的将使这个答案很长.如果您对特定作者如何处理线程安全感兴趣,我建议您发布另一个问题. (正如Spring Batch文档所述)

P.S: The example links that I give above, use FlatFileItemReader with TaskExecutor without mentioning at all possible thread-safety issues..

如果你看一下coherence示例,你会看到它们清楚地修改了图6中的CoherenceBatchWriter.java.它们首先创建mapBatch局部变量,以便多个线程拥有自己的Map副本.此外,如果您深入研究Coherence API,您会发现返回的NamedCache是​​线程安全的.

你提供的第二个链接看起来非常冒险,因为Writer没有做任何事情来避免竞争条件.这个例子确实是多线程步骤的错误使用.来源：https://www.icode9.com/content-1-274251.html