在java中使用多线程解析和编写txt文件

时间:2017-11-03 13:48:05

标签: java xml multithreading parsing

我有很多xml文件。每个xml文件都包含太多的行和标记。在这里,我必须解析它们并使用xml的文件名写入.txt文件。这需要快速完成。越快越好。

xml文件的示例:

<text>
   <paragraph>
         <line>
             <character>g</character>
             <character>o</character>
                         .....
          </line>
          <line>
             <character>k</character>
                         .....
          </line>
   </paragraph>
</text>
<text>
   <paragraph>
         <line>
             <character>c</character>
                         .....
          </line>
   </paragraph>
</text>

文本文件示例:

go..
k..

c..

如何在java中解析许多xml文件并使用多线程编写许多文本文件?

我应该从哪里开始解决问题?我用来解析的方法会影响速度吗?如果影响,哪种方法比其他方法快?

我没有多线程的经验。我应该如何构建一个多线程结构才能有效?

感谢任何帮助。提前谢谢。

修改

我需要一些帮助。我使用SAX进行解析。我对线程池,多线程,java8功能进行了一些研究。我尝试了一些代码块,但总时间没有变化。如何在我的代码中添加多个线程结构或java8功能(Lambda Expressions,Parallelism等)?

3 个答案:

答案 0 :(得分:3)

在这种情况下要注意的事项。

  1. 在许多情况下,尝试使用多线程一次写入多个文件是完全没有意义的。所有这一切通常都是在不必要的情况下锻炼磁头。
  2. 写入磁盘解析也可能是瓶颈。您最好将xml解析为缓冲区,然后在一次命中中将整个缓冲区写入磁盘。
  3. 解析器的速度不太可能显着影响整个过程的时间。与解析相比,您的系统几乎肯定会花费多的时间阅读和写作。
  4. 快速检查一些真实的测试数据将是非常宝贵的。尝试很好地估计能够影响的时间。
    • 通过将几千个样本文件读入内存来确定近似的总读取时间,因为仍然需要采用该时间,但是您需要进行并行处理。
    • 以类似方式估算近似总写入时间
    • 将两者放在一起,并将其与您的总执行时间进行比较,以便阅读,解析和编写这些相同的文件。这应该可以让您了解通过并行可以节省多少时间。
  5. 并行性并不总是慢速运行过程的答案。通过使用适当的硬件,您通常可以显着提高吞吐量。

答案 1 :(得分:0)

首先,您确定需要更快或多线程吗?过早优化是万恶之源。如果你不小心的话,你可以很容易地让你的程序变得更加复杂,以获得不重要的收益,而多线程肯定会让事情变得更加复杂。

然而,针对实际问题: 首先以单线程方式解决这个问题。然后考虑如何在多个线程中拆分此问题。 (例如,拥有一个xml文件和线程池,并且每个线程在其空闲时都会抓取一个xml文件,直到该池为空)向您报告此过程中的任何位置。

用于解析的方法会影响速度,因为不同的解析库具有不同的行为特征。但同样,你确定你需要绝对最快的吗?

答案 2 :(得分:0)

如果您在XSLT(2.0或更高版本)中编写代码,使用collection()函数来解析源文件,并使用xsl:result-document指令来编写结果文件,那么您将能够只需在Saxon-EE下运行代码即可评估多线程的效果,该代码会自动将多线程应用于这些结构。通常根据我的经验,这种程序的速度提高了大约3倍。

这是使用功能声明性语言的好处之一:因为没有可变状态,多线程是无痛的。

LATER

我将添加关于使用DOM或SAX的补充问题的答案。从我们可以看到,输出文件是输入中<character>元素的串联,所以如果你在XSLT 3.0中编写它,它将是这样的:

<xsl:mode on-no-match="shallow-skip">
<xsl:template match="characters">
  <xsl:value-of select="."/>
</xsl:template>

如果是这种情况,那么当然不需要为每个输入文档构建树表示,并且在SAX中编码它将相当容易。或者,如果您遵循我使用Saxon-EE的建议,您可以使转换成为可流动的,以避免树木构建。然而,这是否有用实际上取决于源文档的大小。你还没有给我们任何数字,所以给出具体的性能建议几乎是不可能的。

如果您要使用基于树的表示,那么DOM是您可以选择的最差的。它是其中一种情况,其中有六种更好的替代方案,但因为它们只有20%更好,世界上大多数仍然使用DOM,认为它更多&#34;标准&#34;。我会选择XOM或JDOM2。

如果您准备花费无限的时间对其进行编码以获得最后一盎司的执行速度,那么SAX就是您的选择。然而,对于大多数项目来说,程序员价格昂贵且计算机价格便宜,所以这是错误的权衡。