我有一个案例，在中我需要读取一个包含近100000个逻辑记录的平面文件。每个逻辑记录由nx128个字符组成。即A型：3x128，B型：4-5 X 128等，其中最大可能n为6。
应用程序必须读取文件并处理记录。问题是，只有当我们读取每个nx128分区的前52个字符时，才能确定"n"。
你能建议我可以重复使用的任何设计模式或任何有效的算法吗？
注意：1。性能是一个重要的标准，因为应用程序每天都需要处理成千上万这样的文件。2.数据不以行分隔。这是一个类似长字符串的模式
您可以采用主-工作（或主-从）模式，其中主线程将负责读取数据的前52个字符，以确定记录的长度。然后，主控器可以将读取和处理记录的实际工作推迟到工作线程，并再次移动到下一个记录以仅读取前52个字符。每个工作人员将负责（重新）打开文件并处理特定范围的字符；需要向工人提供该信息。
由于我还没有看到文件的结构，我只能发布一些可能的限制或关注点供实现者思考：
- 一个有效和高性能的实现将依赖于为工作线程提供文件指针和工作线程应该处理的数据长度的能力。换句话说，工作线程实际上应该以随机访问模式读取文件，而不是让主线程进行读取（串行）。如果不能执行随机访问，那么就无法优化主工作模式
- 不建议生成新的工作线程。使用线程池。这也意味着您可以根据池的大小限制打开的文件描述符的数量
- 将进一步的请求排队以处理字符范围，以防池用完。这样，母版就可以继续工作，直到最后一条记录被读取为止
- 跨记录的依赖关系将要求您序列化处理这些记录。如果每个记录都可以在自己的线程上处理，而不需要其他线程的结果可用，那么在采用这种方法时应该不会遇到任何困难
除非你能更改格式，否则你必须解决它。
您可以为每个文件创建一个索引，但您必须读取一次才能构建索引（但这样做可以节省多次）