Mirth Connect v3.5.2.b204读取大CSV文件时出现Java堆空间错误

我之前帮几个团队搞定过Mirth处理大CSV文件的类似问题，结合你用的v3.5.2.b204版本、CSV转HL7 v2.4的场景，还有File Reader+TCP Sender的配置，给你几个针对性的解决思路，按优先级来：

Heap Space Error本质是JVM分配的内存不够装下整个文件和处理过程中的临时对象，调整堆内存是最直接的办法：

• 找到Mirth安装目录下的conf/mirth.properties文件（Windows一般在C:\Program Files\Mirth Connect\conf，Linux在/opt/mirthconnect/conf），修改wrapper.java.maxmemory参数——比如从默认的512改成2048（2G）或者4096（4G），具体看你的服务器内存（如果服务器有8G以上内存，设4G完全没问题）。修改后重启Mirth服务生效。
• 如果你是用Windows服务运行Mirth，别直接改properties文件！打开服务管理器，找到Mirth Connect服务，右键选「属性」，切换到「Java」标签页，调整-Xmx参数的值（比如改成-Xmx4096m），再重启服务。

默认的File Reader会把整个CSV文件塞进内存，147MB的文件肯定扛不住，必须改成逐行流处理：

• 打开你的File Reader连接器配置，在「Reader Settings」里找到「Read Mode」，选择Stream（流模式），而不是默认的Entire File。这样Mirth会逐行读取、处理、发送，内存占用会大幅降低。
• 确认「File Processing Mode」已经设为Move to Directory，并且已处理目录的路径正确、Mirth有读写权限——这能避免处理完的文件被重复读取。

转换逻辑如果写得太粗放，也会额外消耗内存：

• 在Transformer里处理CSV转HL7时，别把整行的所有字段都存在全局变量里，用到哪个字段直接取就行，减少不必要的对象存储。
• 用Mirth内置的CSVParser工具类来解析行数据，比自己写split()分割的效率更高，内存占用也更小：

  // 流模式下，message.getRawData()就是当前处理的一行CSV
  var csvParser = new org.mule.util.CSVParser();
  var fields = csvParser.parse(message.getRawData());
  // 用fields数组构建HL7消息，比如fields[0]是第一个字段，以此类推
  var hl7Msg = new org.mule.hl7.HL7Message("MSH|^~\&|...");
  // 填充HL7字段的逻辑...
  

• 处理完的临时对象可以主动设为null，帮助JVM更快回收内存，比如不用的fields变量可以写fields = null;。

如果TCP Sender一次性发送太多消息，也会导致内存里堆积大量待发送的HL7对象：

• 打开TCP Sender配置，在「Connection Settings」里关掉「Batch Mode」，或者把批量大小设得小一点（比如10条）。
• 把「Max Concurrent Connections」设为1（如果目标HL7系统不支持高并发的话），避免同时建立多个连接发送消息，减少内存占用。

你提到Mirth持续读取文件无法完成，大概率是处理过程中出错但没正确处理，导致文件被反复重试：

• 去Mirth Dashboard的「Logs」标签，或者安装目录下的logs/mirth.log里看具体错误日志——比如某一行CSV格式有问题（比如多了个引号），导致转换失败，Mirth就会一直重试这一行，看起来像“持续读取”。
• 在File Reader的「Error Handling」里，把「On Error」设为Move to Error Directory，这样出错的文件会被移到错误目录，不会一直重复处理。
• 先拿一小段CSV测试（比如复制前100行到测试文件），确认转换逻辑没有问题，再跑整个大文件，避免因为个别错误卡主整个流程。

内容的提问来源于stack exchange，提问作者Sully007