用于处理固定宽度文件的高效模式

时间:2011-06-24 16:48:15

标签: java file file-io apache-commons streamreader

我有一个案例,我需要读取一个包含近100000个逻辑记录的平面文件。每个逻辑记录由nx128个字符部分组成。即A型:3x128,B型:4-5 X 128等,其中最大可能n为6。

应用程序必须读取文件并处理记录。问题是'n'只有在我们读取每个nx128分区的前52个字符时才能确定。

您能否建议我可以重复使用的任何设计模式或任何有效的算法来执行此操作?

注意:1。性能是一个重要的标准,因为应用程序需要每天处理数千个这样的文件。 2.数据不是由行分隔的。它是一个像字符串

的长字符串

2 个答案:

答案 0 :(得分:1)

除非您可以更改格式,否则必须解决它。

您可以为每个文件创建一个索引,但是您必须阅读一次才能构建索引(但这样可以节省多次这样做)

答案 1 :(得分:1)

您可以采用主工作(或主从)模式,其中主线程负责读取数据的前52个字符以确定记录的长度。然后,主设备可以将读取和处理记录的实际工作推迟到工作线程,并再次移动到下一个记录以仅读取前52个字符。每个工作人员将负责(重新)打开文件并处理特定范围的字符;需要向工人提供这些信息。

因为,我还没有看到文件的结构,我只能发布一些可能的限制或担忧,让实施者思考:

  • 一个有效且高效的实现将依赖于为工作线程提供文件指针以及工作者应该处理的数据长度的能力。简单来说,工作线程应该以随机访问模式实际读取文件,而不是让主机进行读取(这是串行的)。如果您无法执行随机访问,则无法进行优化主工作模式。
  • 不建议产生新的工作线程。使用线程池。这也意味着您可以根据池的大小限制打开的文件描述符的数量。
  • 在池耗尽的情况下排队进一步处理字符范围的请求。这样,主人可以继续工作,直到读完最后一条记录。
  • 跨记录的依赖关系将要求您序列化处理记录。如果每个记录都可以在它自己的线程上处理,而不需要其他线程的结果可用,那么采用这种方法就不会遇到任何困难。