第三次改动：
这个时候，我采用了流控相同的思路，就是在处理完一定数据量的数据后，我们进行一次flush操作，将内存中数据刷到文件中，免得一次性刷，同时因为我们一般是整数的W级数据，所以定义一个常量为3000（全局多个地方需要刷数据，好改动），作为flush标示。因为采用3000的话，最后一次我们刷的只有1000的数据量，同时关闭IO需要开销，所以能够在一定程度上降低CPU，同时发现在第一次flush的时候CPU会较高，越后CPU会越低，不知道什么原因。
Java代码
{
if (3000 == i)
{
read.flush()l
}
}
OK ,又可以开工进行测试了，我是费了九牛二虎之力开动了TOMCAT（机子太差），哈哈，终于成功了。CPU从原来的100%降到了10%左右，很有成就感，嘿嘿。这样就将给测试区测试了。但是，但是，测试告诉我一个很不幸的消息，CPU还是很高，这个是为什么呢？
仔细看看了，原来TMD应用的服务器跟DB在一台服务器上，气死老夫了。采用一次性传递数据的片刻，ORACLE会使CPU会飙到100%，而且处理这么多数据的时候也会持续5s左右的时间一直处在该位。这个时候咋办呢？这个就需要第四次改动了。
第四次改动：
这个时候，首先改动的是存储过程，采用了动态变量绑定，同时调整commit;的次数，在1000，3000，5000，10000条记录的时候提交数据，结果调试后，没什么改观，没则，只好换个思路。
启用存储过程，在java端想办法，最简单的方法还是启用原来的批量提交方式，修改为一定数量数据后提交，因为这个提交，并在提交后sleep，方式CPU一直处在这个状态。
伪代码就是
Java代码
{
If (3000 == i)
{
//提交数据到DB
//清零标示，清空临时list
Thread.sleep();
}
}
就这么简单。提交调试后，发现java端不会消耗很高的CPU，在第一次提交批量数据时会到30%左右，第二三次会降到15%左右，同时ORACLE消耗的CPU在第一次会100%，但是持续时间很短，就1s的时间，在达到这样的效果后，领导说可以了。总算结束了这段优化过程。
简单的说，我这种方式不过是用时间换CPU的性能，只使用与对于时间要求不是很高，更要求CPU的性能的场景。
