多线程能提高Oracle的入库速度吗
最近常常和同事们讨论“系统架构”，其中有不免提到如何使用“多线程”来改善系统性能。有些同事普遍有一种“认为”：他们认为“多线程”是改善系统性能的“灵丹妙药”，他们简单的认为，“多线程”导致“并发”，而并发显然是改善性能的好途径。
在讨论这个问题前，我们还是复习一下基本概念。我们从“进程”、“多进程”、“线程”、“多线程”说起。
进程 ：进程就是已执行程式的实体(参见：wiki)。简单点说就是：运行着的程序(好像和上句差不多:) )。
“多进程”其实就是“多任务”：进程是现今“分时系统”以及“多任务操作系统”的基本运作单位。操作系统在同一段时间内加载多个程式和行程到内存中，并分时间片完成(或称多任务)，以在一个CPU上表现出同时执行的感觉。Unix, Windows XP, Linux都可以称为多任务操作系统；XP也可以勉强称为“分时系统”；Unix和Linux当然可以被称为“分时系统”)。当我们执行DOS(DOS是单任务OS，虽然它有所谓的TSR技术)，必须把上一个程序退出来，才能执行下面的程序。而在Windows环境下，我们可以一边“下载电影”，一边“听 mp3”，同时还可以“上网”。这就是多任务带给我们的好处。
线程 ：具体概念参见wiki。线程和进程的核心区别就是“是否存在独立的地址空间”。每一个进程都有自己的“地址空间”，而线程是共享“地址空间”的。这带来的好处就是：线程间的切换成本要显著小于进程间的切换成本。我们举一个通俗(是不是庸俗？)例子来说明进程和线程的区别。有一个花心的男孩，同时和两个女孩谈恋爱，但由于这个“恋爱过程”始终在空间上是不能够交叉的，也就是说这两个女孩始终碰不到面，这对于这个男孩来说这就是“多任务”。如果象韦小宝一样，他的大小老婆都住在一起，他可以和他的七个老婆打情骂俏，由于他们在同一个“地址空间”因此这就是“多线程”。显然花心男的“任务(进程)”的切换需要改变“地址空间”--跑来跑去，还需要分别记住对不同“女友”的不同许诺，以及不同的“誓言”----保存环境变量，这个明显要比韦小宝“多进程”的切换要辛苦的多。
多线程能够为我们带来什么好处呢？我们从“下载电影”说起，比如，我可以“多任务”的起N个ftp程序，分别从不同的地址下载N部电影。你可以通过定时查看每小时你的磁盘减少了多少空间，来判断你每小时下载了多少内容(这称为吞吐量)。虽然这种方法，可能我们有很高的吞吐量，但也显然存在不少缺点，比如，无法加快单一电影的下载速度(十个妈妈不可能在一个月生出一个宝宝来)。具有“多线程”的功能的“迅雷”就有许多优点了，它可以把同一部电影分解成N部分，分别从不同的网址下载，当某一个网址下载链接不可用时，它有可以自动切换到其他网址上(线程间的切换成本是很小的)。但这里有些前提，常常被我们忽略：
1、我们的CPU有足够的能力起多个线程(在配置不高的机器上，会感到迅雷很占资源)；
2、我们的硬盘读写速度要远高于“下载速度”。
3、下载电影的网站的网速并不高。这点特别重要，如果我们是1Mbit的带宽，而ftp下载某电影已经能够稳定在1Mbit(256K字节)，我们换用迅雷除了让我们的机器慢下来，是不能够改善下载速度的。
4、起N个ftp客户端程序下载的吞吐量，不比迅雷差。只是你下载的电影都只是开头部分。
关于“多线程”技术能否给系统提速，核心的问题在于找到系统的“性能瓶颈”。
再看看我们正在开发的系统存在的问题吧。我们正在开发的系统是一个网管系统，它需要大量的采集网络设备数据到数据库中，同时提供用户界面给网络运维人员查看是否存在网络告警、网络性能数据、以及网络的拓扑情况。
1、多线程采集数据入库(数据库)能改善系统性能吗？
显然不能！由于有大量的采集数据等待进入数据库，以及存在大量的Oracle后台运算，使得当前的系统瓶颈在Oracle上，而Oracle的性能瓶颈在磁盘I/O上(有大量的全表扫描SQL以及大量的写入操作)。这里的情况和上面迅雷利用“多线程”改善性能的情况一点也不同，因此改善 Oracle的磁盘I/O才是正道。
2、Java连接池技术能够改善入库速度吗？
我们为了改善采集速度，采用了多台采集机并发采集网络数据，这些采集机都需要把采集的数据入库到Oracle。Java连接池技术主要是为了解决DB连接过程的成本问题，对于存在大量短时连接的Web应用，就凸显起好处了(参见：Java jdbc数据库连接池总结)。而我们的采集过程本来就是一个连续的不间断过程。其实这里每个采集机只需要抓住一个Oracle连接不放手就可以了，完全没有必要每5分钟一次的采集过程完成后就释放连接，随后再重新建立Oracle连接。更加让人无法理解的是每一个采集机的连接池竟然高达10个连接，这有什么用？
总而言之，我们需要改善Oracle的整体入库“吞吐量”，线程在里显然无用武之处。
)
