我们可以在计算机上运行各种计算机软件程序。每一个运行的程序可能包括多个独立运行的线程(Thread)。 线程(Thread)是一份独立运行的程序,有自己专用的运行栈。线程有可能和其他线程共享一些资源,比如,内存,文件,数据库等。 当多个线程同时读写同一份共享资源的时候,可能会引起冲突。这时候,我们需要引入线程“同步”机制,即各位线程之间要有个先来后到,不能一窝蜂挤上去抢作一团。 同步这个词是从英文synchronize(使同时发生)翻译过来的。我也不明白为什么要用这个很容易引起误解的词。既然大家都这么用,咱们也就只好这么将就。 线程同步的真实意思和字面意思恰好相反。线程同步的真实意思,其实是“排队”:几个线程之间要排队,一个一个对共享资源进行操作,而不是同时进行操作。 因此,关于线程同步,需要牢牢记住的第一点是:线程同步就是线程排队。同步就是排队。线程同步的目的就是避免线程“同步”执行。这可真是个无聊的绕口令。 关于线程同步,需要牢牢记住的第二点是 “共享”这两个字。只有共享资源的读写访问才需要同步。如果不是共享资源,那么就根本没有同步的必要。 关于线程同步,需要牢牢记住的第三点是,只有“变量”才需要同步访问。如果共享的资源是固定不变的,那么就相当于“常量”,线程同时读取常量也不需要同步。至少一个线程修改共享资源,这样的情况下,线程之间就需要同步。 关于线程同步,需要牢牢记住的第四点是:多个线程访问共享资源的代码有可能是同一份代码,也有可能是不同的代码;无论是否执行同一份代码,只要这些线程的代码访问同一份可变的共享资源,这些线程之间就需要同步。 为了加深理解,下面举几个例子。 有两个采购员,他们的工作内容是相同的,都是遵循如下的步骤: (1)到市场上去,寻找并购买有潜力的样品。 (2)回到公司,写报告。 这两个人的工作内容虽然一样,他们都需要购买样品,他们可能买到同样种类的样品,但是他们绝对不会购买到同一件样品,他们之间没有任何共享资源。所以,他们可以各自进行自己的工作,互不干扰。 这两个采购员就相当于两个线程;两个采购员遵循相同的工作步骤,相当于这两个线程执行同一段代码。 下面给这两个采购员增加一个工作步骤。采购员需要根据公司的“布告栏”上面公布的信息,安排自己的工作计划。 这两个采购员有可能同时走到布告栏的前面,同时观看布告栏上的信息。这一点问题都没有。因为布告栏是只读的,这两个采购员谁都不会去修改布告栏上写的信息。 下面增加一个角色。一个办公室行政人员这个时候,也走到了布告栏前面,准备修改布告栏上的信息。 如果行政人员先到达布告栏,并且正在修改布告栏的内容。两个采购员这个时候,恰好也到了。这两个采购员就必须等待行政人员完成修改之后,才能观看修改后的信息。 如果行政人员到达的时候,两个采购员已经在观看布告栏了。那么行政人员需要等待两个采购员把当前信息记录下来之后,才能够写上新的信息。 上述这两种情况,行政人员和采购员对布告栏的访问就需要进行同步。因为其中一个线程(行政人员)修改了共享资源(布告栏)。而且我们可以看到,行政人员的工作流程和采购员的工作流程(执行代码)完全不同,但是由于他们访问了同一份可变共享资源(布告栏),所以他们之间需要同步。 同步锁 前面讲了为什么要线程同步,下面我们就来看如何才能线程同步。 线程同步的基本实现思路还是比较容易理解的。我们可以给共享资源加一把锁,这把锁只有一把钥匙。哪个线程获取了这把钥匙,才有权利访问该共享资源。 生活中,我们也可能会遇到这样的例子。一些超市的外面提供了一些自动储物箱。每个储物箱都有一把锁,一把钥匙。人们可以使用那些带有钥匙的储物箱,把东西放到储物箱里面,把储物箱锁上,然后把钥匙拿走。这样,该储物箱就被锁住了,其他人不能再访问这个储物箱。(当然,真实的储物箱钥匙是可以被人拿走复制的,所以不要把贵重物品放在超市的储物箱里面。于是很多超市都采用了电子密码锁。) 线程同步锁这个模型看起来很直观。但是,还有一个严峻的问题没有解决,这个同步锁应该加在哪里? 当然是加在共享资源上了。反应快的读者一定会抢先回答。 没错,如果可能,我们当然尽量把同步锁加在共享资源上。一些比较完善的共享资源,比如,文件系统,数据库系统等,自身都提供了比较完善的同步锁机制。我们不用另外给这些资源加锁,这些资源自己就有锁。 但是,大部分情况下,我们在代码中访问的共享资源都是比较简单的共享对象。这些对象里面没有地方让我们加锁。 读者可能会提出建议:为什么不在每一个对象内部都增加一个新的区域,专门用来加锁呢?这种设计理论上当然也是可行的。问题在于,线程同步的情况并不是很普遍。如果因为这小概率事件,在所有对象内部都开辟一块锁空间,将会带来极大的空间浪费。得不偿失。 于是,现代的编程语言的设计思路都是把同步锁加在代码段上。确切的说,是把同步锁加在“访问共享资源的代码段”上。这一点一定要记住,同步锁是加在代码段上的。 同步锁加在代码段上,就很好地解决了上述的空间浪费问题。但是却增加了模型的复杂度,也增加了我们的理解难度。 现在我们就来仔细分析“同步锁加在代码段上”的线程同步模型。 首先,我们已经解决了同步锁加在哪里的问题。我们已经确定,同步锁不是加在共享资源上,而是加在访问共享资源的代码段上。 其次,我们要解决的问题是,我们应该在代码段上加什么样的锁。这个问题是重点中的重点。这是我们尤其要注意的问题:访问同一份共享资源的不同代码段,应该加上同一个同步锁;如果加的是不同的同步锁,那么根本就起不到同步的作用,没有任何意义。 这就是说,同步锁本身也一定是多个线程之间的共享对象。 Java语言的synchronized关键字 为了加深理解,举几个代码段同步的例子。 不同语言的同步锁模型都是一样的。只是表达方式有些不同。这里我们以当前最流行的Java语言为例。Java语言里面用synchronized关键字给代码段加锁。整个语法形式表现为 synchronized(同步锁) { // 访问共享资源,需要同步的代码段 } 这里尤其要注意的就是,同步锁本身一定要是共享的对象。 … f1() { Object lock1 = new Object(); // 产生一个同步锁 synchronized(lock1){ // 代码段 A // 访问共享资源 resource1 // 需要同步 } } 上面这段代码没有任何意义。因为那个同步锁是在函数体内部产生的。每个线程调用这段代码的时候,都会产生一个新的同步锁。那么多个线程之间,使用的是不同的同步锁。根本达不到同步的目的。 同步代码一定要写成如下的形式,才有意义。 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 A // 访问共享资源 resource1 // 需要同步 } 你不一定要把同步锁声明为static或者public,但是你一定要保证相关的同步代码之间,一定要使用同一个同步锁。 讲到这里,你一定会好奇,这个同步锁到底是个什么东西。为什么随便声明一个Object对象,就可以作为同步锁? 在Java里面,同步锁的概念就是这样的。任何一个Object Reference都可以作为同步锁。我们可以把Object Reference理解为对象在内存分配系统中的内存地址。因此,要保证同步代码段之间使用的是同一个同步锁,我们就要保证这些同步代码段的synchronized关键字使用的是同一个Object Reference,同一个内存地址。这也是为什么我在前面的代码中声明lock1的时候,使用了final关键字,这就是为了保证lock1的Object Reference在整个系统运行过程中都保持不变。 一些求知欲强的读者可能想要继续深入了解synchronzied(同步锁)的实际运行机制。Java虚拟机规范中(你可以在google用“JVM Spec”等关键字进行搜索),有对synchronized关键字的详细解释。synchronized会编译成 monitor enter, … monitor exit之类的指令对。Monitor就是实际上的同步锁。每一个Object Reference在概念上都对应一个monitor。 这些实现细节问题,并不是理解同步锁模型的关键。我们继续看几个例子,加深对同步锁模型的理解。 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 A // 访问共享资源 resource1 // 需要同步 } } … f2() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 B // 访问共享资源 resource1 // 需要同步 } } 上述的代码中,代码段A和代码段B就是同步的。因为它们使用的是同一个同步锁lock1。 如果有10个线程同时执行代码段A,同时还有20个线程同时执行代码段B,那么这30个线程之间都是要进行同步的。 这30个线程都要竞争一个同步锁lock1。同一时刻,只有一个线程能够获得lock1的所有权,只有一个线程可以执行代码段A或者代码段B。其他竞争失败的线程只能暂停运行,进入到该同步锁的就绪(Ready)队列。 每一个同步锁下面都挂了几个线程队列,包括就绪(Ready)队列,待召(Waiting)队列等。比如,lock1对应的就绪队列就可以叫做lock1 - ready queue。每个队列里面都可能有多个暂停运行的线程。 注意,竞争同步锁失败的线程进入的是该同步锁的就绪(Ready)队列,而不是后面要讲述的待召队列(Waiting Queue,也可以翻译为等待队列)。就绪队列里面的线程总是时刻准备着竞争同步锁,时刻准备着运行。而待召队列里面的线程则只能一直等待,直到等到某个信号的通知之后,才能够转移到就绪队列中,准备运行。 成功获取同步锁的线程,执行完同步代码段之后,会释放同步锁。该同步锁的就绪队列中的其他线程就继续下一轮同步锁的竞争。成功者就可以继续运行,失败者还是要乖乖地待在就绪队列中。 因此,线程同步是非常耗费资源的一种操作。我们要尽量控制线程同步的代码段范围。同步的代码段范围越小越好。我们用一个名词“同步粒度”来表示同步代码段的范围。 同步粒度 在Java语言里面,我们可以直接把synchronized关键字直接加在函数的定义上。 比如。 … synchronized … f1() { // f1 代码段 } 这段代码就等价于 … f1() { synchronized(this){ // 同步锁就是对象本身 // f1 代码段 } } 同样的原则适用于静态(static)函数 比如。 … static synchronized … f1() { // f1 代码段 } 这段代码就等价于 …static … f1() { synchronized(Class.forName(…)){ // 同步锁是类定义本身 // f1 代码段 } } 但是,我们要尽量避免这种直接把synchronized加在函数定义上的偷懒做法。因为我们要控制同步粒度。同步的代码段越小越好。synchronized控制的范围越小越好。 我们不仅要在缩小同步代码段的长度上下功夫,我们同时还要注意细分同步锁。 比如,下面的代码 public static final Object lock1 = new Object(); … f1() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 A // 访问共享资源 resource1 // 需要同步 } } … f2() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 B // 访问共享资源 resource1 // 需要同步 } } … f3() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 C // 访问共享资源 resource2 // 需要同步 } } … f4() { synchronized(lock1){ // lock1 是公用同步锁 // 代码段 D // 访问共享资源 resource2 // 需要同步 } } 上述的4段同步代码,使用同一个同步锁lock1。所有调用4段代码中任何一段代码的线程,都需要竞争同一个同步锁lock1。 我们仔细分析一下,发现这是没有必要的。 因为f1()的代码段A和f2()的代码段B访问的共享资源是resource1,f3()的代码段C和f4()的代码段D访问的共享资源是resource2,它们没有必要都竞争同一个同步锁lock1。我们可以增加一个同步锁lock2。f3()和f4()的代码可以修改为: public static final Object lock2 = new Object(); … f3() { synchronized(lock2){ // lock2 是公用同步锁 // 代码段 C // 访问共享资源 resource2 // 需要同步 } } … f4() { synchronized(lock2){ // lock2 是公用同步锁 // 代码段 D // 访问共享资源 resource2 // 需要同步 } } 这样,f1()和f2()就会竞争lock1,而f3()和f4()就会竞争lock2。这样,分开来分别竞争两个锁,就可以大大较少同步锁竞争的概率,从而减少系统的开销。 信号量 同步锁模型只是最简单的同步模型。同一时刻,只有一个线程能够运行同步代码。 有的时候,我们希望处理更加复杂的同步模型,比如生产者/消费者模型、读写同步模型等。这种情况下,同步锁模型就不够用了。我们需要一个新的模型。这就是我们要讲述的信号量模型。 信号量模型的工作方式如下:线程在运行的过程中,可以主动停下来,等待某个信号量的通知;这时候,该线程就进入到该信号量的待召(Waiting)队列当中;等到通知之后,再继续运行。 很多语言里面,同步锁都由专门的对象表示,对象名通常叫Monitor。 同样,在很多语言中,信号量通常也有专门的对象名来表示,比如,Mutex,Semphore。 信号量模型要比同步锁模型复杂许多。一些系统中,信号量甚至可以跨进程进行同步。另外一些信号量甚至还有计数功能,能够控制同时运行的线程数。 我们没有必要考虑那么复杂的模型。所有那些复杂的模型,都是最基本的模型衍生出来的。只要掌握了最基本的信号量模型——“等待/通知”模型,复杂模型也就迎刃而解了。 我们还是以Java语言为例。Java语言里面的同步锁和信号量概念都非常模糊,没有专门的对象名词来表示同步锁和信号量,只有两个同步锁相关的关键字——volatile和synchronized。 这种模糊虽然导致概念不清,但同时也避免了Monitor、Mutex、Semphore等名词带来的种种误解。我们不必执着于名词之争,可以专注于理解实际的运行原理。 在Java语言里面,任何一个Object Reference都可以作为同步锁。同样的道理,任何一个Object Reference也可以作为信号量。 Object对象的wait()方法就是等待通知,Object对象的notify()方法就是发出通知。 具体调用方法为 (1)等待某个信号量的通知 public static final Object signal = new Object(); … f1() { synchronized(singal) { // 首先我们要获取这个信号量。这个信号量同时也是一个同步锁 // 只有成功获取了signal这个信号量兼同步锁之后,我们才可能进入这段代码 signal.wait(); // 这里要放弃信号量。本线程要进入signal信号量的待召(Waiting)队列 // 可怜。辛辛苦苦争取到手的信号量,就这么被放弃了 // 等到通知之后,从待召(Waiting)队列转到就绪(Ready)队列里面 // 转到了就绪队列中,离CPU核心近了一步,就有机会继续执行下面的代码了。 // 仍然需要把signal同步锁竞争到手,才能够真正继续执行下面的代码。命苦啊。 … } } 需要注意的是,上述代码中的signal.wait()的意思。signal.wait()很容易导致误解。signal.wait()的意思并不是说,signal开始wait,而是说,运行这段代码的当前线程开始wait这个signal对象,即进入signal对象的待召(Waiting)队列。 (2)发出某个信号量的通知 … f2() { synchronized(singal) { // 首先,我们同样要获取这个信号量。同时也是一个同步锁。 // 只有成功获取了signal这个信号量兼同步锁之后,我们才可能进入这段代码 signal.notify(); // 这里,我们通知signal的待召队列中的某个线程。 // 如果某个线程等到了这个通知,那个线程就会转到就绪队列中 // 但是本线程仍然继续拥有signal这个同步锁,本线程仍然继续执行 // 嘿嘿,虽然本线程好心通知其他线程, // 但是,本线程可没有那么高风亮节,放弃到手的同步锁 // 本线程继续执行下面的代码 … } } 需要注意的是,signal.notify()的意思。signal.notify()并不是通知signal这个对象本身。而是通知正在等待signal信号量的其他线程。 以上就是Object的wait()和notify()的基本用法。 实际上,wait()还可以定义等待时间,当线程在某信号量的待召队列中,等到足够长的时间,就会等无可等,无需再等,自己就从待召队列转移到就绪队列中了。 另外,还有一个notifyAll()方法,表示通知待召队列里面的所有线程。 这些细节问题,并不对大局产生影响。 绿色线程 绿色线程(Green Thread)是一个相对于操作系统线程(Native Thread)的概念。 操作系统线程(Native Thread)的意思就是,程序里面的线程会真正映射到操作系统的线程,线程的运行和调度都是由操作系统控制的 绿色线程(Green Thread)的意思是,程序里面的线程不会真正映射到操作系统的线程,而是由语言运行平台自身来调度。 当前版本的Python语言的线程就可以映射到操作系统线程。当前版本的Ruby语言的线程就属于绿色线程,无法映射到操作系统的线程,因此Ruby语言的线程的运行速度比较慢。 难道说,绿色线程要比操作系统线程要慢吗?当然不是这样。事实上,情况可能正好相反。Ruby是一个特殊的例子。线程调度器并不是很成熟。 目前,线程的流行实现模型就是绿色线程。比如,stackless Python,就引入了更加轻量的绿色线程概念。在线程并发编程方面,无论是运行速度还是并发负载上,都优于Python。 另一个更著名的例子就是ErLang(爱立信公司开发的一种开源语言)。 ErLang的绿色线程概念非常彻底。ErLang的线程不叫Thread,而是叫做Process。这很容易和进程混淆起来。这里要注意区分一下。 ErLang Process之间根本就不需要同步。因为ErLang语言的所有变量都是final的,不允许变量的值发生任何变化。因此根本就不需要同步。 final变量的另一个好处就是,对象之间不可能出现交叉引用,不可能构成一种环状的关联,对象之间的关联都是单向的,树状的。因此,内存垃圾回收的算法效率也非常高。这就让ErLang能够达到Soft Real Time(软实时)的效果。这对于一门支持内存垃圾回收的语言来说,可不是一件容易的事情。
生产者/消费者模型 有了信号量这个利器,我们就可以处理比较复杂的线程同步模型了。 首先,我们来看一个比较简单的生产者/消费者模型。还是以Java代码为例。 public static final Object signal = new Object(); public static final char[] buf = new char[1024]; // 需要同步访问的共享资源 // 生产者代码 … produce() { for(… ) { // 循环执行 synchronized(signal){ // 产生一些东西,放到 buf 共享资源中 signal.notify(); //然后通知消费者 signal.wait(); // 然后自己进入signal待召队列 } } } // 消费者代码 … consume() { for(… ) { // 循环执行 synchronized(signal){ signal.wait(); // 进入signal待召队列,等待生产者的通知 // 读取buf 共享资源里面的东西 signal.notify(); // 然后通知生产者 } } } 上述的生产者/消费者模型的实现非常简单,只用了一个信号量signal。这只是一段示意代码。 实际上的生产者/消费者模型的实现可能非常复杂。可以引入buf已满或者已空的判断,可以引入更多的信号量,也可以引入一个环状的buf链。但那些都是性能优化方面的工作,基本的信号量工作方式还是不变的。 生产者/消费者模型是典型的Coroutine。而且,当消费者或者生产者线程进入待召队列的时候,当前的运行栈状态就暂时保存在系统当中,这种状况又是典型的Continuation。 因此,我们完全可以用信号量机制自己实现Coroutine和Continuation。其实,那些在语法层面上支持Coroutine和Continuation的语言,内部实现原理也是采用类似的信号量同步机制。
读写模型 读写模型是一个稍微复杂一些的模型。 一份共享资源允许多个读者同时读取。但是只要有一个写者在写这份共享资源,任何其他的读者和写者都不能访问这份共享资源。 读写模型实现起来,不仅需要信号量机制,还需要额外的读者计数和写者计数。 public static final Object signal = new Object(); public static int readers = 0; public static int writers = 0; // 读者代码 … read() { for(… ) { // 循环执行 synchronized(signal){ while( writers > 0 ) signal.wait(); // 如果有人在写,那么就放弃执行,进入待召队列 // 能够到达这里,说明没有人在写 readers ++ ; // 增加一个读者计数,表示本线程在读取 } // 这里出了synchronized范围,释放同步锁.以便其他线程读取. // 进行一些读取操作 synchronized(signal){ readers --; // 读取完成,减少一个读者计数,表示本线程不在读取 signal.notifyAll(); // 通知待召队列里面的所有其他线程 } } } // 写者代码 … write() { for(… ) { // 循环执行 synchronized(signal){ while( writers > 0 || readers > 0) signal.wait();// 如果有人在写或读,那么就放弃执行,进入待召队列 // 能够到达这里,说明没有人在写,也没有人在读 writers ++ ; // 增加一个写者计数,表示本线程在写 // 进行一些写操作 writers --; // 读取完成,减少一个读者计数,表示本线程不在写 signal.notifyAll(); // 通知待召队列里面的所有其他线程 } } } 上述代码只是一段示意代码。实际应用中,人们通常抽取出来一个专门的读写同步锁。 interface ReadWriteLock { … getReadLock(); … releaseReadLock(); … getWriteLock(); … releaseWriteLock(); } 具体的实现原理也是类似的信号量同步机制。 class RWLock { … readers, writers; … synchronized … getReadLock() { // 相当于synchronized(this) … while( writers > 0 ) this.wait(); // 这里我们把RWLock对象本身作为信号量 readers++; } …synchronized … releaseReadLock(){ //相当于synchronized(this) readers--; this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量 } …synchronized … getWriteLock(){// 相当于synchronized(this) while( writers > 0 || readers > 0 ) this.wait(); // 这里我们把RWLock对象本身作为信号量 writers++; } …synchronized … releaseWriteLock(){// 相当于synchronized(this) writers--; this.notifyAll(); // // 这里我们把RWLock对象本身作为信号量 } } 具体用法是 public static final RWLock lock = new RWLock(); … read() { lock.getReadLock(); // 读取 lock.releaseReadLock(); } … write() { lock.getWriteLock(); // 读取 lock.releaseWriteLock(); } 这种用法要求在执行一些处理之前,一定要执行某项特殊操作,处理之后一定也要执行某项特殊操作。这种人为的顺序性,无疑增加了代码的耦合度,降低了代码的独立性。很有可能会成为线程死锁和资源操作冲突的根源。 这点一直让我不安,可是没有找到方法避免。毕竟,死锁或者资源操作冲突,是线程的固有问题。 很巧的是,正在我惴惴不安的时候,我的一个朋友提供了一个信息。Sun公司根据JCR,决定在jdk1.5中引入关于concurrency(并发)的部分。 以下这个网址是concurrency部分的util.concurrent一个实现。非常好的信息。对于处理多线程并发问题,很有帮助。 http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html 里面提供了一个ReadWriteLock类,标准用法如下。 Standard usage of ReadWriteLock: class X { ReadWriteLock rw; // ... public void read() throws InterruptedException { rw.readLock().acquire(); try { // ... do the read } finally { rw.readlock().release() } } public void write() throws InterruptedException { rw.writeLock().acquire(); try { // ... do the write } finally { rw.writelock().release() } } } 我们可以看到,ReadWriteLock同样要求调用的顺序——aquire()和release()。我对自己的例子增强了一点信心。 我又查看了WriterPreferenceReadWriteLock类,看到里面成对的方法,startRead(),endRead();startWrite(),endWrite()。我的心情完全放松了下来。我的思路虽然粗糙,但大体的方向是正确的。
Concurrent Map Concurrent Map的最简单的实现方法是直接用java.util.HashTable类,或者用Collections.synchronizedMap() 修饰某个Map。 这样获得的Map能够保证读写同步,但是,并发读的时候,也必须同步,串行读取,效率很低。这个思路显然不适合。 Doug Lea提供了一个Concurrent工具包, http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html 包括Lock, ReadWriteLock, CurrentHashMap, CurrentReaderHashMap等类。JDK1.5引入了这些类,作为java.util.concurrent Package。 我设想了一下,CurrentHashMap应该是采用ReadWriteLock实现读写同步。代码看起来应该像这个样子。
- // my guess
- class CocurrentHashMap
- {
- Private Map map = null;
- final ReadWriteLock rwLock = new …. ;
- final Lock readLock = rwLock.readLock();
- final Lock writeLock = rwLock.writeLock();
- // decorate the map as concurrent
- public CocurrentHashMap(Map m){
- map = m;
- }
- // all write method, like put, putAll, remove, clear
- public void putAll(Map m){
- writeLock.lock();
- try{
- map.putAll(m);
- }finally{
- writeLock.unlock();
- }
- }
- // all read method. like get, containsKey, containsValue, entrySet()
- public Object get(Object key){
- readLock.lock();
- try{
- return map.get(key);
- }finally{
- readLock.unlock();
- }
- };
- // as we can see, in such places it is convenient to use AOP here. :-)
// my guess
class CocurrentHashMap
{
Private Map map = null;
final ReadWriteLock rwLock = new …. ;
final Lock readLock = rwLock.readLock();
final Lock writeLock = rwLock.writeLock();
// decorate the map as concurrent
public CocurrentHashMap(Map m){
map = m;
}
// all write method, like put, putAll, remove, clear
public void putAll(Map m){
writeLock.lock();
try{
map.putAll(m);
}finally{
writeLock.unlock();
}
}
// all read method. like get, containsKey, containsValue, entrySet()
public Object get(Object key){
readLock.lock();
try{
return map.get(key);
}finally{
readLock.unlock();
}
};
// as we can see, in such places it is convenient to use AOP here. :-)
但看了CurrentHashMap 的代码,发现不是这样。其中的实现比较复杂,把Table分成段进行分别管理。那个内部类 Segment extends ReentrantLock。 里面的 readValueUnderLock 方法里面用了lock。
- /**
- * Read value field of an entry under lock. Called if value
- * field ever appears to be null. This is possible only if a
- * compiler happens to reorder a HashEntry initialization with
- * its table assignment, which is legal under memory model
- * but is not known to ever occur.
- */
- V readValueUnderLock(HashEntry<K,V> e) {
- lock();
- try {
- return e.value;
- } finally {
- unlock();
- }
- }
/**
* Read value field of an entry under lock. Called if value
* field ever appears to be null. This is possible only if a
* compiler happens to reorder a HashEntry initialization with
* its table assignment, which is legal under memory model
* but is not known to ever occur.
*/
V readValueUnderLock(HashEntry<K,V> e) {
lock();
try {
return e.value;
} finally {
unlock();
}
}
我们再来看CurrentReaderHashMap, “A version of Hashtable that supports mostly-concurrent reading, but exclusive writing.” http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentReaderHashMap.java 但是它的 read ( get, contains, size …) 方法里面用到了synchronized。还是要获得系统锁。
线程池 线程是一种比较昂贵的资源。有些系统为了重用线程,引入了线程池的机制。 线程池的工作原理如下: 首先,系统会启动一定数量的线程。这些线程就构成了一个线程池。 当有任务要做的时候,系统就从线程池里面选一个空闲的线程。然后把这个线程标记为“正在运行”。然后把任务传给这个线程执行。线程执行任务完成之后,就把自己标记为“空闲”。 这个过程并不难以理解。难以理解的是,一般来说,线程执行完成之后,运行栈等系统资源就会释放,线程对象就被回收了。一个已经完成的线程,又如何能回到线程池的空闲线程队列中呢? 秘诀就在于,线程池里面的线程永远不会执行完成。线程池里面的线程,都是一个无穷循环。具体代码如下: Thread pooledThread { … theTask …. // theTask成员变量,表示要执行的任务 … run() { while( true ) { // 永不停止的循环 signal.wait(); // 等待系统的通知 theTask.run(); // 执行任务 } } } 系统只需要调用 signal.notify() 就可以启动一个空闲线程。
|
返回顶楼 |