今天在用 processing(http://zh.wikipedia.org/wiki/Processing) 编写处理 midi 文件的程序的时候，遇到了一个问题。程序主要是读取分析 midi ，然后用波形模拟 midi 中的信息，最后记录相应内容，创建 wav 文件。在使用 WaveFileWriter 写文件的时候，因为波形数据较多，使用 new byte[139708800] 创建了一个大小约为134M的 byte 数组，导致程序抛出 java.lang.OutOfMemoryError: Java heap space。
起初我想到可能原因是 JVM 的 HeapSize 大小不够，在 cmd 中查看，发现初始大小是下图这样的。也就是初始堆大小为 16777216 bits，也就是16M；堆的最大值是268435456 bits，也就是256M。而我需要创建的byte数组是134M，很可能heap space会不够。于是我就在系统变量里添加了"_JAVA_OPTIONS",将值设为"-Xmx1024m"。
起初我以为经过这样的设置，应该就没有问题了。但是事实情况是，我重新运行了几次程序，有时候不会OOME，有时候会OOME。于是我就用jconsole去监控JVM内存使用情况，发现不管是否抛出OOME，堆内存都分配了134M的空间给我的byte数组。（jconsole是安装jdk时候自带的，如果配置了java环境变量，可以直接在cmd中输入"jconsole"即可启动）
于是我猜想，是不是因为没有将 -Xms 和 -Xmx 设置为一样，从而导致垃圾回收之后，虚拟机重新分配内存不及时，导致错误率先抛出？按照 Java SE hotspot 的说明文档，如果 InitialHeapSize 和 MaxHeapSize 不一样，那么在运行过程中 JVM 会自动调整内存大小，默认值是上升20%。（具体值可在cmd中查看）这样的话，为了分配134M的内存，需要经过多次增长，所以有时内存重新分配快，就没有OOME，有时候重新分配慢，就会有OOME。不管怎样，为了避开这个问题，我就将"_JAVA_OPTIONS"系统变量的值设定为"-Xms1024m -Xmx1024m"。不过这次出现了新的问题，也是OOME，但是不是java heap space,而是outputstream.write(byte[]) (native method) 出现了OOME。原因是我将JVM的内存设置太大，导致Direct Memory不够了，执行本地方法的时候内存不足。于是我重新调整JVM的内存大小为512M，最终解决了问题。
解决问题的关键点在三处：
- OutOfMemoryError: java heap space ，可以通过上调Xmx解决。
- OutOfMemoryError 如果是由于本地方法产生的，应该下调Xmx。这种解决问题的技巧在周志明的《深入理解java虚拟机》中有讲到。
- 学会用jconsole去监控内存使用情况。
这次最终还残留了一个问题没有解决，为什么只设置-Xmx参数之后，OOME会间歇性出现。我只是猜想原因，真正的原因还有待验证。并且我还没有想到好的验证方法，希望有经验的朋友能帮忙指出！