参数优化性能调优

与众多的程序化交易软件类似,我们的产品也有一个强大的功能叫参数优化。然而,最近这个功能却被暴露出来性能问题,优化参数的穷举组合仅在2000个左右,优化线程数为20,每个线程负责执行一个策略,也就是说正常情况下执行100轮就执行完毕,但却在执行了10轮左右也就是执行了200个策略左右时,进度条就变得越来越缓慢。这种情况下最容易让人想到的原因无非有2个:CPU独占和内存泄漏。于是,采用jstack(命令行执行:jstack pid,如果内容太多还可以先输出到文件:jstack pid > tmp.txt)先看一下堆栈情况,果不其然,有2个线程在执行java.util.HashMap.get()时被阻塞(BLOCKED)了,看到这个不禁心中窃喜,这么容易就找到原因了。记得以前遇到过一次,在多线程并发的情况下,java.util.HashMap.get()极有可能导致CPU100%,并且永久阻塞,当然网上也曾经有人遇到过此类问题,参见:http://my.oschina.net/javagg/blog/3358

于是,我很爽快地把HashMap改成了ConcurrentHashMap,并再一次进行测试。很遗憾,事情并没有就此结束,更让人意外的是,这仅仅是恶梦的开始,当然这是后话。第二次执行时,策略没有在10轮左右的时候变慢,而是把这个时间延后了,变成了在50轮左右的时候变慢。这说明刚才的改动明显是起到了一定的功效,于是再次用jstack查看,这次又发现了一个新的现象:

"SyncEventProcessor@strategyId#1840[DEMO名字#1840]" prio=6 tid=0x0c792000 nid=0x4784 waiting for monitor entry [0x0f54f000..0x0f54fae8]
   java.lang.Thread.State: BLOCKED (on object monitor)
 at java.text.DecimalFormat.format(DecimalFormat.java:578)
 - waiting to lock <0x04245330> (a java.text.DigitList)
 at java.text.DecimalFormat.format(DecimalFormat.java:507)
 at java.text.NumberFormat.format(NumberFormat.java:269)
 at com.dfitc.stp.indicator.Indicator.toString(Indicator.java:509)
 at java.lang.String.valueOf(String.java:2827)
 at java.lang.StringBuilder.append(StringBuilder.java:115)
 at com.dfitc.stp.strategy.CustomStrategy._updateIndicators(CustomStrategy.java:248)
 at com.dfitc.stp.strategy.CustomStrategy.preProcessEvent(CustomStrategy.java:789)
 at com.dfitc.stp.strategy.CustomStrategy.processEvent(CustomStrategy.java:898)
 - locked <0x0774b118> (a com.dfitc.strategy.demo.PrinterStrategy$$EnhancerByCGLIB$$9ff2c180)
 at com.dfitc.stp.strategy.CustomStrategy._processImmediately(CustomStrategy.java:219)
 at com.dfitc.trading.hedge.test.SyncEventProcessor.processNormalEvent(SyncEventProcessor.java:342)
 at com.dfitc.trading.hedge.test.SyncEventProcessor.run(SyncEventProcessor.java:395)
 at java.lang.Thread.run(Thread.java:619)

这次阻塞的对象变成了java.text.DecimalFormat.format(),原因是我在Indicator.toString()中会使用DecimalFormat对象去进行数字格式化操作,但为了节约内存,把DecimalFormat对象设成了静态的,这样所有的Indicator在格式化时都会使用同一个DecimalFormat进行格式化,通过查看DecimalFormat的源码得知,这个类在格式化时会对自身的实例变量digitList加锁:

private StringBuffer format(double number, StringBuffer result, FieldDelegate delegate) {
  ...
  synchronized(digitList) {

    ...

  }
}

这是不是瓶颈还不知道,但是考虑到把Indicator中的DecimalFormat改成非静态的也无伤大雅,于是索性改掉。但第三次进行测试时,问题依旧。没办法,继续在进度条变慢时用jstack进行多次查看对比,仍没看出来问题。但前面的努力也并非徒劳无功,至少让缓慢的进度条出现时间延后了,不仅如此,还可以断定剩下的问题一定是出在内存泄漏上了。经过仔细审阅代码,发现策略执行时,是一组一组顺序执行,策略实例在每一组执行完毕后都会进行销毁,所以可以推断策略本身不会出现内存泄漏。但是策略执行完后,会把执行的结果(即运行后的分析结果,如盈亏、回撤等)存储起来,2000个策略当然最终就会存储2000份。不过这一块并不是由我负责开发的,我只是在策略下单产生成交时调用,然后在策略执行完毕后获取分析结果。据猜测,这个功能很可能在计算完结果后,没有将用于计算结果的原始数据清除。我马上找到该模块的开发人员确认,事实证明我的猜测是对的。于是我让该开发人员马上进行修正,在适当的时候清除掉原始的数据。改完后马上进行第四轮测试,原以为事件可以就此终结,但从执行结果来看,和第一次改动一样,问题仅仅是得到了缓解,并没有根除,策略在执行到60轮时又出现了同样的问题。没办法,只能继续查找原因,我再次对代码进行了详细的审阅,仍没有发现问题,束手无策时我想起了java自带的工具jmap,步骤仅需2步:

1.保存内存快照: jmap -dump:file=c:\dump.dat pid,不过保存后的文件是二进制的,无法用文本编辑器查看

2.查看内存快照,这个需要先安装一个eclipse插件Memory Analyzer(jdk自带的工具也可以查看,不过据说Memory Analyzer更直观),在线安装地址:http://download.eclipse.org/mat/1.2/update-site/,安装后打开对应的Perspective,就可以将刚才保留的dump.dat打开查看了

这真是一个神奇的工具,还没有等我自己去看哪有问题,它已经直接告诉我了:

一目了然,有一个叫做HisStrategyContext的类进入了我的视线,这个类开辟的内存空间占用了所有优化策略的82%。经过查看代码发现,这个类会存储策略执行过程中需要持久化的所有缓存信息,包括委托、成交回报、撤单回报等等,虽然在策略被“删除”时会执行清空缓存的操作,但在参数优化时,所有的策略都没有“删除”这个操作,只有“停止”。

于是,对代码进行了改进,策略停止时也追加清除缓存的处理。我坚信这次找到了性能瓶颈,所以索性把穷举组合增大到10000个,不出所料,再一次执行时,每一组都运行稳定:

group(1):size=20, current=(20/11664), time=42s
group(2):size=20, current=(40/11664), time=39s
group(3):size=20, current=(60/11664), time=37s
...
group(498):size=20, current=(9960/11664), time=34s
group(499):size=20, current=(9980/11664), time=34s
group(500):size=20, current=(10000/11664), time=34s

至少,在执行了167组(3340个) 策略时,一切正常。

通过这次调优经历,总结如下:

1.HashMap是非线程安全的,get()方法在多线程竞争时会导致CPU永久100%的可怕事情发生,所以,如果可能出现多个线程同时访问Map集合,需要使用更安全的ConcurrentHashMap代替

2.数字格式化的类DecimalFormat,其format方法也会有竞争,所以在不影响性能的情况下,尽量不要在多线程中使用DecimalFormat

3.再谨慎的编码习惯也难以确保不会出现内存泄漏,必要时使用工具可以让事情事半功倍

你可能感兴趣的:(参数优化性能调优)