Thread的层次结构

要弄清楚Thread的层次结构，必须先弄清楚它的参照系。看看“The Futures of Ruby Threading”这段话：“Current stable releases of Ruby use user space threads (also called "green threads"), which means that the Ruby interpreter takes care of everything to do with threads. This is in contrast to kernel threads, where the creation, scheduling and synchronization is done with OS syscalls, which makes these operations costly, at least compared to their equivalents in user space threads.”这里的用户空间线程和内核线程是相对于Ruby解释器来说的。如果把参照系换成操作系统，此处的内核线程只是一个用户空间线程。

常说Java线程是Native thread，是说Java的一个线程映射到操作系统上的一个用户线程。往下随后怎么映射就要看操作系统的实现了。可以看看Solaris的线程模型，这里也有些说明资料。

不过Java线程也并不一定是一一映射的，比如Jikes RVM虚拟机，采用了M:N模型，而不是大家经常看到的1:1，具体资料可以看这里。BEA的JRockit是两个都有，既支持1:1模型，也支持M:N模型，叫Thin Thread。

在JVM上实现了M:N模型，当然在操作系统上也可以实现M:N模型，只是层次不同，抽象级别不同。象Solaris就实现了M:N模型，不过这个模型在Solaris 9中已经放弃，为什么？实现太难。“It is not to say that a good implementation of the M:N model is impossible,but simply that a good 1:1 implementation is probably sufficient. ”想更进一步了解Solaris多线程的发展历程，看这个pdf吧（www.sun.com/software/whitepapers/solaris9/multithread.pdf）。

了解清楚Thread的层次结构，碰到Green Thread，Native Thread，User space Thread，Kernel Thread时才不会糊涂。

Thread被过度使用

既然Thread质疑声一片，为什么它仍能够存在呢？原因有：
（1）某些应用程序天生就具有并发特性，而且需要共享地址空间和各种资源，比如数据库服务器。
（2）进程方案开销大。
（3）Java语言大行其道，使得绝大部分程序员认为并发编程唯一也是最好的方式就是采用多线程，而且在Java语言中创建一个线程非常简单。

对于第二点，只有线程创建，线程同步，线程加锁等开销比进程方案开销小，才会真正获益。只是来个线程创建和进程创建开销的比较，那也太天真了。此处，我认为还要包括开发，维护进程并发程序和线程并发程序两种方式之间的开销对比。毕竟，除了机器时间，人的时间也很宝贵。

对于第三点，Java是不是会在以后考虑另外的并发模式。象建立在JVM之上的Scala语言就在采用Actor模式。多个选择，总是不错的主意。不然搞得我们这些开发人员都去用Thread，使得Thread被过度使用，破坏Thread的名声。


附：如果想了解Thread在哪些方面被广泛批评，请参考如下资料：
（1）《The Art of Unix Programming》的“Threads-Threat or Menace？”
（2）“Why Threads Are a Bad Idea”
（3）“The Problem with Threads”

Green Thread不比Native Thread差

在Ruby实现中，Ruby1.8采用的是Green thread，JRuby和XRuby采用的是Native thread，Rubinius既支持Green thread，也支持Native thread。Ruby1.9将由Green thread转向Native thread。Green thread有哪些不足呢？

在“Ruby Userspace Threads vs GUI tookits Roundup”中重点强调了Green Thread的一个不足：Blocking syscall将阻塞所有其余的线程，而且这个问题在GUI和网络开发中将随处碰到。另外，Green Thread不能有效挖掘多核和多CPU的性能。于是大家都把视线转向Native thread。我对Native thread不感冒，主要是因为shared state concurrency问题多多。具体有哪些，相信你看完“The problem with threads”就会很清楚了。

现在，Erlang很好的解决了Green Thread存在的问题。它没有采用m：1模式，而是采用了m：n模式。Erlang runtime以n个native thread运行，每个都有一个自己的调度器。而且，Erlang采用shared nothing concurrency，可以把Native Thread存在的问题都抛之脑后。

看来XRuby的thread实现可以好好借鉴一下Erlang的并发范式。在看了“The Futures of Ruby Threading”之后，更坚定了应该朝这方面努力。

多核意味着什么？

过去，提升CPU性能的方法有：

• 时钟速度
• 执行优化
• 缓存

此时用户程序无须修改，就可以获得CPU性能提升所带来的好处。现在，提升CPU性能的方法：

• 超线程
• 多核
• 缓存

此时虽然缓存能，但超线程和多核CPU对现在的绝大多数应用，几乎不会有任何影响。多核还说不定会降慢程序的运行，因为多核带来的是更强的并行处理能力、更高的计算密度和更低的时钟频率。如果不采用并发好好利用硬件资源，多核CPU真的是浪费。

另外，还有一些问题需要注意。有了多核，有时候还是感觉应用程序慢，此时问题可能就不是出在CPU上。要知道就算是单核，在日常工作中，CPU的利用率远没有达到100%。有时候，应用程序的瓶颈可能是在I/O，可能在网络，或者数据库，等等。有了计算能力，还有很多工作要做。