通过top发现，JavaA大部分时间占用的内存实际并不多，但是占用的虚拟内存很大。马上修改该程序启动时的
JVM参数，将最大内存调的小一些，果然就不出错了。由于JavaA必须在内存中处理大量的数据，内存太小了就可
能处理不了，因此这么改是不可行的。
上网查的过程中，发现一些有趣的东西。Linux内核中可以设置内存的overcommit_memory属性，意思是Linux
内核认为有些程序很保守，总是申请较多的内存，但实际并不使用，因此在设置overcommit后，内核将不检查剩
余内存是否够用，直接允许所有的内存分配。可能大部分情况下没问题，但是仔细想想，还是有很大的问题，最
严重的是改变了malloc的语义，调用者不能通过返回值来判断内存是否分配成功了。另外一个问题是，万一内
存真的不够了怎么办？Linux中有个特殊的进程，OOM(out-of-memory)进程终止者，其功能就是在内存真的不
够时，随机或者根据某些原则杀掉一些进程。选择进程的原则好像不能精确控制，那将是一件很恐怖的事情。。。
顺道小小八卦一下，当时还有不少人研究如何选择要杀掉的进程，提出了不少的改进方法，于是有人看不下去了，
说了一个很有意思的故事，某航空公司为了节省油钱，每次飞行并不加满油，飞行途中要是超员了就挑一些乘客
扔下去，于是大家兴高采烈的讨论应该扔谁下去。。。
Runtime.getRuntime().exec(cmd)的执行流程分析
继续上网查，大概意思是Java程序调用外部程序时可能需要分配跟父进程同等大小的内存。这就奇怪了，
比如说，我随便调用一下ls命令，也需要很多内存吗？肯定是Java调用外部程序的接口里处理比较特殊。嗯，
刚好JDK也开源，看看源码去。
分析SUN JDK 1.5 SRC，找到Runtime.getRuntime().exec(cmd)的执行流程：
java.lang.Runtime.exec(cmd);
--java.lang.ProcessBuilder.start();
----java.lang.ProcessImpl.start();
------Java_java_lang_UNIXProcess_forkAndExec() in j2se/src/solaris/native/java/lang
/UNIXProcess_md.c
--------1). fork(); 2). execvp();
man fork知道，fork产生的子进程需要复制父进程在内存中的所有数据内容（代码段、数据段、堆栈段），
由于全部复制开销较大，因此Linux已经采用copy-on-write机制，即只是复制页表，共享内容，在有改变的时
候再去申请内存和复制数据。
因此我分析，问题的原因可能是这样的，虽然Linux早已在fork()中采用copy-on-write机制，但是JVM调
用fork()后，Java进程里的其它线程往往会被调度回来继续执行，修改了自己的内存，而这个时候
execvp()还没有执行，于是悲剧就发生了，内存都要重新复制一遍。
解决办法
最后说说解决办法，既然问题出在可能会申请分配跟父进程同等大小的内存，那么我限制父进程使用的内存就
可以了。前面说了我们正在开发的JavaA必须使用比较大的内存，可是JavaA不一定是父进程呀，我可以单独运
行一个Java程序，称为JavaB吧，由它负责调用外部程序，JavaA调用我们封装后的接口与之通信，等待外部程
序结束，从而与Runtime.getRuntime().exec(cmd)的语义保持一致。这个单独运行的JavaB只需要很小很小的内
存，因此不太可能出现无法分配内存，进而无法执行外部程序的问题了