优化在JTextArea中进行大文件的查找替换过程

优化在JTextArea中进行大文件的查找替换过程

现象、问题描述

在“综合管理应用平台”客户端的立即批处理面板，导入 10M大小的命令脚本文件（假设该脚本文件的所有命令均为“QRY GOL:;”），如果用户需要把命令文件中的所有“GOL”替换成“LOG”,大约需要耗费几个小时的时间，严重影响立即批处理面板查找替换的使用效果。

关键过程、根本原因分析

在立即批处理面板中查找替换过程实现如下:

1、查找满足匹配的字符串。得到匹配字符串的起始和终止位置。

2、在事件派发线程中更新JTextArea中匹配的字符串。刷新客户端界面。

3、循环第一步，直到完成为止。

效率的瓶颈是一次查找替换，一次更新客户端界面。10M的批处理脚本文件大约能容纳100万行“QRY LOG:;”命令，即需要完成100万次查找替换和更新界面操作，直接的表现是客户端替换的速度非常慢。

结论、解决方案及效果

基于以上性能瓶颈分析，有如下方案可以采纳：

1、用一个字符数组保存从 JTextArea中取出的字符串。在实现的过程中再用另外的一个字符数组保存替换的结果。完成替换操作后一次更新客户端界面。

2、用一个字符数组保存从 JTextArea中取出的字符串。同时在该字符数组中进行替换。完成替换操作后一次更新客户端界面。

3、一次从 JTextArea中取出一部分字符串(一次32K)。完成替换后更新界面。再取出一部分字符串进行更新。直到替换完成为止。

方案分析：

第一个方案：在立即批处理面板中导入10M的命令脚本文件，客户端已经占用120M左右的内存。客户端最大的堆内存设定为256M。在实现的过程中采用两个数组来保存命令脚本。由于两个数组均保存10M大小的字符串，如果客户端正在执行某个费内存的操作，在查找替换的过程中必定会发生内存溢出(OutOfMemoryError)的错误。为了规避方案一的错误，采用方案二。但是在方案二中替换的过程只采用一个数组，必定会导致数组长度频繁波动，多次出现申请新数组的动作，效率也是较慢。综合第一、第二种方案，第三种方案采用从JTextArea中部分取出字符串（在实现的过程中验证一次取32K较适合），即采用多次申请小块的内存替代一次申请大块的内存，虽然会产生较多的临时变量，但这些临时变量能被JVM及时回收，避免发生内存溢出错误。替换的过程也是采用同方案一一样，用两个字符数组，一个保存源字符串，一个保存替换结果。完成一次替换，更新一次界面。从实现的结果看，收效甚好。

第三种方案性能分析：

10M的命令脚本文件（若命令脚本中均为“QRY GOL:;”）大约有100万行。按原先的算法把“GOL”全部替换成“LOG”需要100万次界面更新；若采用第三种方案一次取出32K进行更新，需要320次界面更新。前者更新界面的次数是后者的3125倍。即后者界面更新的效率较前者大约提升3000倍。从实现完成的效果看，完成一次10M批处理脚本的替换过程大约2分钟左右。

经验总结、预防措施和规范建议

在进行需要耗费大内存操作的过程中，在不影响程序运行效率的前提下可以转化成只需要小内存的部分执行操作。部分执行全部完成等价于整个大操作完成。即在申请小内存的环境下完成需要耗费大内存的操作。化整为零，各个击破。