java线程
来源:互联网 发布:买淘宝店铺哪个网站 编辑:程序博客网 时间:2024/06/15 19:52
线程安全与不安全
作为一个Java web开发人员,很少也不需要去处理线程,因为服务器已经帮我们处理好了。记得大一刚学Java的时候,老师带着我们做了一个局域网聊天室,用到了AWT、Socket、多线程、I/O,编写的客户端和服务器,当时做出来很兴奋,回学校给同学们演示,感觉自己好NB,呵呵,扯远了。上次在百度开发者大会上看到一个提示语,自己写的代码,6个月不看也是别人的代码,自己学的知识也同样如此,学完的知识如果不使用或者不常常回顾,那么还不是自己的知识。大学零零散散搞了不到四年的Java,我相信很多人都跟我一样,JavaSE基础没打牢,就急忙忙、兴冲冲的搞JavaEE了,然后学习一下前台开发(html、css、javascript),有可能还搞搞jquery、extjs,再然后是Struts、hibernate、spring,然后听说找工作得会linux、oracle,又去学,在这个过程中,是否迷失了,虽然学习面很广,但就像《神雕侠侣》中黄药师评价杨过,博而不精、杂而不纯,这一串下来,感觉做Java开发好难,并不是学着难,而是知识面太广了,又要精通这个,又要精通那个,这只是我迷茫时候的想法,现在我已经找到方向了。
回归正题,当我们查看JDK API的时候,总会发现一些类说明写着,线程安全或者线程不安全,比如说StringBuilder中,有这么一句,“将StringBuilder
的实例用于多个线程是不安全的。如果需要这样的同步,则建议使用StringBuffer
。 ”,那么下面手动创建一个线程不安全的类,然后在多线程中使用这个类,看看有什么效果。
Count.java:
在这个类中的count方法是计算1一直加到10的和,并输出当前线程名和总和,我们期望的是每个线程都会输出55。
ThreadTest.java:
这里启动了10个线程,看一下输出结果:
只有Thread-0线程输出的结果是我们期望的,而输出的是每次都累加的,这里累加的原因以后的博文会说明,那么要想得到我们期望的结果,有几种解决方案:
1. 将Count中num变成count方法的局部变量;
2. 将线程类成员变量拿到run方法中,这时count引用是线程内的局部变量;
3. 每次启动一个线程使用不同的线程类,不推荐。
上述测试,我们发现,存在成员变量的类用于多线程时是不安全的,不安全体现在这个成员变量可能发生非原子性的操作,而变量定义在方法内也就是局部变量是线程安全的。想想在使用struts1时,不推荐创建成员变量,因为action是单例的,如果创建了成员变量,就会存在线程不安全的隐患,而struts2是每一次请求都会创建一个action,就不用考虑线程安全的问题。所以,日常开发中,通常需要考虑成员变量或者说全局变量在多线程环境下,是否会引发一些问题
线程同步synchronized和volatile
通过一个简单的例子说明了线程安全与不安全,在例子中不安全的情况下输出的结果恰好是逐个递增的(其实是巧合,多运行几次,会产生不同的输出结果),为什么会产生这样的结果呢,因为建立的Count对象是线程共享的,一个线程改变了其成员变量num值,下一个线程正巧读到了修改后的num,所以会递增输出。
要说明线程同步问题首先要说明Java线程的两个特性,可见性和有序性。多个线程之间是不能直接传递数据交互的,它们之间的交互只能通过共享变量来实现。拿上篇博文中的例子来说明,在多个线程之间共享了Count类的一个对象,这个对象是被创建在主内存(堆内存)中,每个线程都有自己的工作内存(线程栈),工作内存存储了主内存Count对象的一个副本,当线程操作Count对象时,首先从主内存复制Count对象到工作内存中,然后执行代码count.count(),改变了num值,最后用工作内存Count刷新主内存Count。当一个对象在多个内存中都存在副本时,如果一个内存修改了共享变量,其它线程也应该能够看到被修改后的值,此为可见性。多个线程执行时,CPU对线程的调度是随机的,我们不知道当前程序被执行到哪步就切换到了下一个线程,一个最经典的例子就是银行汇款问题,一个银行账户存款100,这时一个人从该账户取10元,同时另一个人向该账户汇10元,那么余额应该还是100。那么此时可能发生这种情况,A线程负责取款,B线程负责汇款,A从主内存读到100,B从主内存读到100,A执行减10操作,并将数据刷新到主内存,这时主内存数据100-10=90,而B内存执行加10操作,并将数据刷新到主内存,最后主内存数据100+10=110,显然这是一个严重的问题,我们要保证A线程和B线程有序执行,先取款后汇款或者先汇款后取款,此为有序性。本文讲述了JDK5.0之前传统线程的同步方式,更高级的同步方式可参见Java线程(八):锁对象Lock-同步问题更完美的处理方式。
下面同样用代码来展示一下线程同步问题。
TraditionalThreadSynchronized.java:创建两个线程,执行同一个对象的输出方法。
运行结果:
显然输出的字符串被打乱了,我们期望的输出结果是zhangsanlisi,这就是线程同步问题,我们希望output方法被一个线程完整的执行完之后再切换到下一个线程,Java中使用synchronized保证一段代码在多线程执行时是互斥的,有两种用法:
1. 使用synchronized将需要互斥的代码包含起来,并上一把锁。
这把锁必须是需要互斥的多个线程间的共享对象,像下面的代码是没有意义的。
每次进入output方法都会创建一个新的lock,这个锁显然每个线程都会创建,没有意义。
2. 将synchronized加在需要互斥的方法上。
这种方式就相当于用this锁住整个方法内的代码块,如果用synchronized加在静态方法上,就相当于用××××.class锁住整个方法内的代码块。使用synchronized在某些情况下会造成死锁,死锁问题以后会说明。使用synchronized修饰的方法或者代码块可以看成是一个原子操作。
每个锁对(JLS中叫monitor)都有两个队列,一个是就绪队列,一个是阻塞队列,就绪队列存储了将要获得锁的线程,阻塞队列存储了被阻塞的线程,当一个线程被唤醒(notify)后,才会进入到就绪队列,等待CPU的调度,反之,当一个线程被wait后,就会进入阻塞队列,等待下一次被唤醒,这个涉及到线程间的通信,下一篇博文会说明。看我们的例子,当第一个线程执行输出方法时,获得同步锁,执行输出方法,恰好此时第二个线程也要执行输出方法,但发现同步锁没有被释放,第二个线程就会进入就绪队列,等待锁被释放。一个线程执行互斥代码过程如下:
1. 获得同步锁;
2. 清空工作内存;
3. 从主内存拷贝对象副本到工作内存;
4. 执行代码(计算或者输出等);
5. 刷新主内存数据;
6. 释放同步锁。
所以,synchronized既保证了多线程的并发有序性,又保证了多线程的内存可见性。
volatile是第二种Java多线程同步的机制,根据JLS(Java LanguageSpecifications)的说法,一个变量可以被volatile修饰,在这种情况下内存模型(主内存和线程工作内存)确保所有线程可以看到一致的变量值,来看一段代码:
一些线程执行one方法,另一些线程执行two方法,two方法有可能打印出j比i大的值,按照之前分析的线程执行过程分析一下:
1. 将变量i从主内存拷贝到工作内存;
2. 改变i的值;
3. 刷新主内存数据;
4. 将变量j从主内存拷贝到工作内存;
5. 改变j的值;
6. 刷新主内存数据;
这个时候执行two方法的线程先读取了主存i原来的值又读取了j改变后的值,这就导致了程序的输出不是我们预期的结果,要阻止这种不合理的行为的一种方式是在one方法和two方法前面加上synchronized修饰符:
根据前面的分析,我们可以知道,这时one方法和two方法再也不会并发的执行了,i和j的值在主内存中会一直保持一致,并且two方法输出的也是一致的。另一种同步的机制是在共享变量之前加上volatile:
one方法和two方法还会并发的去执行,但是加上volatile可以将共享变量i和j的改变直接响应到主内存中,这样保证了主内存中i和j的值一致性,然而在执行two方法时,在two方法获取到i的值和获取到j的值中间的这段时间,one方法也许被执行了好多次,导致j的值会大于i的值。所以volatile可以保证内存可见性,不能保证并发有序性。
没有明白JLS中为什么使用两个变量来阐述volatile的工作原理,这样不是很好理解。volatile是一种弱的同步手段,相对于synchronized来说,某些情况下使用,可能效率更高,因为它不是阻塞的,尤其是读操作时,加与不加貌似没有影响,处理写操作的时候,可能消耗的性能更多些。但是volatile和synchronized性能的比较,我也说不太准,多线程本身就是比较玄的东西,依赖于CPU时间分片的调度,JVM更玄,还没有研究过虚拟机,从顶层往底层看往往是比较难看透的。在JDK5.0之前,如果没有参透volatile的使用场景,还是不要使用了,尽量用synchronized来处理同步问题,线程阻塞这玩意简单粗暴。另外volatile和final不能同时修饰一个字段,可以想想为什么.
线程协作-生产者/消费者问题
上一篇讲述了线程的互斥(同步),但是在很多情况下,仅仅同步是不够的,还需要线程与线程协作(通信),生产者/消费者问题是一个经典的线程同步以及通信的案例。该问题描述了两个共享固定大小缓冲区的线程,即所谓的“生产者”和“消费者”在实际运行时会发生的问题。生产者的主要作用是生成一定量的数据放到缓冲区中,然后重复此过程。与此同时,消费者也在缓冲区消耗这些数据。该问题的关键就是要保证生产者不会在缓冲区满时加入数据,消费者也不会在缓冲区中空时消耗数据。要解决该问题,就必须让生产者在缓冲区满时休眠(要么干脆就放弃数据),等到下次消费者消耗缓冲区中的数据的时候,生产者才能被唤醒,开始往缓冲区添加数据。同样,也可以让消费者在缓冲区空时进入休眠,等到生产者往缓冲区添加数据之后,再唤醒消费者,通常采用线程间通信的方法解决该问题。如果解决方法不够完善,则容易出现死锁的情况。出现死锁时,两个线程都会陷入休眠,等待对方唤醒自己。该问题也能被推广到多个生产者和消费者的情形。本文讲述了JDK5之前传统线程的通信方式,更高级的通信方式可参见Java线程(九):Condition-线程通信更高效的方式和Java线程(篇外篇):阻塞队列BlockingQueue。
假设有这样一种情况,有一个盘子,盘子里只能放一个鸡蛋,A线程专门往盘子里放鸡蛋,如果盘子里有鸡蛋,则一直等到盘子里没鸡蛋,B线程专门从盘子里取鸡蛋,如果盘子里没鸡蛋,则一直等到盘子里有鸡蛋。这里盘子是一个互斥区,每次放鸡蛋是互斥的,每次取鸡蛋也是互斥的,A线程放鸡蛋,如果这时B线程要取鸡蛋,由于A没有释放锁,B线程处于等待状态,进入阻塞队列,放鸡蛋之后,要通知B线程取鸡蛋,B线程进入就绪队列,反过来,B线程取鸡蛋,如果A线程要放鸡蛋,由于B线程没有释放锁,A线程处于等待状态,进入阻塞队列,取鸡蛋之后,要通知A线程放鸡蛋,A线程进入就绪队列。我们希望当盘子里有鸡蛋时,A线程阻塞,B线程就绪,盘子里没鸡蛋时,A线程就绪,B线程阻塞,代码如下:
输出结果:
程序开始,A线程判断盘子是否为空,放入一个鸡蛋,并且唤醒在阻塞队列的一个线程,阻塞队列为空;假设CPU又调度了一个A线程,盘子非空,执行等待,这个A线程进入阻塞队列;然后一个B线程执行,盘子非空,取走鸡蛋,并唤醒阻塞队列的A线程,A线程进入就绪队列,此时就绪队列就一个A线程,马上执行,放入鸡蛋;如果再来A线程重复第一步,在来B线程重复第二步,整个过程就是生产者(A线程)生产鸡蛋,消费者(B线程)消费鸡蛋。
前段时间看了张孝祥老师线程的视频,讲述了一个其学员的面试题,也是线程通信的,在此也分享一下。
题目:子线程循环10次,主线程循环100次,如此循环100次,好像是空中网的笔试题。
大家注意到没有,在调用wait方法时,都是用while判断条件的,而不是if,在wait方法说明中,也推荐使用while,因为在某些特定的情况下,线程有可能被假唤醒,使用while会循环检测更稳妥。wait和notify方法必须工作于synchronized内部,且这两个方法只能由锁对象来调用。另附这两种方法的JavaDoc说明:
notify
public final void notify()
wait
方法,在对象的监视器上等待。直到当前的线程放弃此对象上的锁定,才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争;例如,唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。
此方法只应由作为此对象监视器的所有者的线程来调用。通过以下三种方法之一,线程可以成为此对象监视器的所有者:
- 通过执行此对象的同步 (Sychronized) 实例方法。
- 通过执行在此对象上进行同步的
synchronized
语句的正文。 - 对于
Class
类型的对象,可以通过执行该类的同步静态方法。
一次只能有一个线程拥有对象的监视器。
IllegalMonitorStateException
- 如果当前的线程不是此对象监视器的所有者。notifyAll
public final void notifyAll()
wait
方法,在对象的监视器上等待。直到当前的线程放弃此对象上的锁定,才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争;例如,唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。
此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify
方法,了解线程能够成为监视器所有者的方法的描述。
IllegalMonitorStateException
- 如果当前的线程不是此对象监视器的所有者。wait
public final void wait(long timeout) throws InterruptedException
notify()
方法或notifyAll()
方法,或者超过指定的时间量。当前的线程必须拥有此对象监视器。
此方法导致当前线程(称之为 T)将其自身放置在对象的等待集中,然后放弃此对象上的所有同步要求。出于线程调度目的,线程 T 被禁用,且处于休眠状态,直到发生以下四种情况之一:
- 其他某个线程调用此对象的 notify 方法,并且线程 T 碰巧被任选为被唤醒的线程。
- 其他某个线程调用此对象的 notifyAll 方法。
- 其他某个线程
中断
线程 T。 - 已经到达指定的实际时间。但是,如果 timeout 为零,则不考虑实际时间,该线程将一直等待,直到获得通知。
在没有被通知、中断或超时的情况下,线程还可以唤醒一个所谓的虚假唤醒 (spurious wakeup)。虽然这种情况在实践中很少发生,但是应用程序必须通过以下方式防止其发生,即对应该导致该线程被提醒的条件进行测试,如果不满足该条件,则继续等待。换句话说,等待应总是发生在循环中,如下面的示例:
synchronized (obj) {while (<condition does not hold>)obj.wait(timeout);... // Perform action appropriate to condition }(有关这一主题的更多信息,请参阅 Doug Lea 撰写的《Concurrent Programming in Java (Second Edition)》(Addison-Wesley, 2000) 中的第 3.2.3 节或 Joshua Bloch 撰写的《Effective Java Programming Language Guide》(Addison-Wesley, 2001) 中的第 50 项。
如果当前线程在等待时被其他线程中断
,则会抛出InterruptedException。在按上述形式恢复此对象的锁定状态时才会抛出此异常。
注意,由于 wait 方法将当前的线程放入了对象的等待集中,所以它只能解除此对象的锁定;可以同步当前线程的任何其他对象在线程等待时仍处于锁定状态。
此方法只应由作为此对象监视器的所有者的线程来调用。请参阅 notify
方法,了解线程能够成为监视器所有者的方法的描述。
timeout
- 要等待的最长时间(以毫秒为单位)。IllegalArgumentException
- 如果超时值为负。IllegalMonitorStateException
- 如果当前的线程不是此对象监视器的所有者。InterruptedException
- 如果在当前线程等待通知之前或者正在等待通知时,另一个线程中断了当前线程。在抛出此异常时,当前线程的中断状态 被清除。wait
public final void wait(long timeout, int nanos) throws InterruptedException
notify()
方法或notifyAll()
方法,或者其他某个线程中断当前线程,或者已超过某个实际时间量。此方法类似于一个参数的 wait
方法,但它允许更好地控制在放弃之前等待通知的时间量。用毫微秒度量的实际时间量可以通过以下公式计算出来:
1000000*timeout+nanos
在其他所有方面,此方法执行的操作与带有一个参数的 wait(long)
方法相同。需要特别指出的是,wait(0, 0) 与wait(0) 相同。
当前的线程必须拥有此对象监视器。该线程发布对此监视器的所有权,并等待下面两个条件之一发生:
- 其他线程通过调用
notify
方法,或notifyAll
方法通知在此对象的监视器上等待的线程醒来。 timeout
毫秒值与nanos
毫微秒参数值之和指定的超时时间已用完。
然后,该线程等到重新获得对监视器的所有权后才能继续执行。
对于某一个参数的版本,实现中断和虚假唤醒是有可能的,并且此方法应始终在循环中使用:
synchronized (obj) {while (<condition does not hold>)obj.wait(timeout, nanos);... // Perform action appropriate to condition }此方法只应由作为此对象监视器的所有者的线程来调用。请参阅
notify
方法,了解线程能够成为监视器所有者的方法的描述。
timeout
- 要等待的最长时间(以毫秒为单位)。nanos
- 额外时间(以毫微秒为单位,范围是 0-999999)。IllegalArgumentException
- 如果超时值是负数,或者毫微秒值不在 0-999999 范围内。IllegalMonitorStateException
- 如果当前线程不是此对象监视器的所有者。InterruptedException
- 如果在当前线程等待通知之前或者正在等待通知时,其他线程中断了当前线程。在抛出此异常时,当前线程的中断状态 被清除。wait
public final void wait() throws InterruptedException
notify()
方法或notifyAll()
方法。换句话说,此方法的行为就好像它仅执行wait(0)调用一样。当前的线程必须拥有此对象监视器。该线程发布对此监视器的所有权并等待,直到其他线程通过调用 notify
方法,或 notifyAll
方法通知在此对象的监视器上等待的线程醒来。然后该线程将等到重新获得对监视器的所有权后才能继续执行。
对于某一个参数的版本,实现中断和虚假唤醒是可能的,而且此方法应始终在循环中使用:
synchronized (obj) {while (<condition does not hold>)obj.wait();... // Perform action appropriate to condition }此方法只应由作为此对象监视器的所有者的线程来调用。请参阅
notify
方法,了解线程能够成为监视器所有者的方法的描述。
IllegalMonitorStateException
- 如果当前的线程不是此对象监视器的所有者。InterruptedException
- 如果在当前线程等待通知之前或者正在等待通知时,另一个线程中断了当前线程。在抛出此异常时,当前线程的中断状态 被清除。 线程中断、线程让步、线程睡眠、线程合并
最近在Review线程专栏,修改了诸多之前描述不够严谨的地方,凡是带有Review标记的文章都是修改过了。本篇文章是插进来的,因为原来没有写,现在来看传统线程描述的不太完整,所以就补上了。理解了线程同步和线程通信之后,再来看本文的知识点就会简单的多了,本文是做为传统线程知识点的一个补充。有人会问:JDK5之后有了更完善的处理多线程问题的类(并发包),我们还需要去了解传统线程吗?答:需要。在实际开发中,无外乎两种情况,一个是开发新内容,另一个是维护原有程序。开发新内容可以使用新的技术手段,但是我们不能保证原有程序是用什么实现的,所以我们需要了解原有的。另外一点,了解传统线程的工作原理,使我们在使用并发包时更加得心应手。
线程中断
void
interrupt()
中断线程。
static boolean
interrupted()
测试当前线程是否已经中断。
boolean
isInterrupted()
测试线程是否已经中断。
interrupt()方法用于中断线程,通常的理解来看,只要某个线程启动后,调用了该方法,则该线程不能继续执行了,来看个小例子:
运行后,我们发现,线程t一直在执行,没有被中断,原来interrupt()是骗人的,汗!其实interrupt()方法并不是中断线程的执行,而是为调用该方法的线程对象打上一个标记,设置其中断状态为true,通过isInterrupted()方法可以得到这个线程状态,我们将上面的程序做一个小改动:
这样的话,线程被顺利的中断执行了。很多人实现一个线程类时,都会再加一个flag标记,以便控制线程停止执行,其实完全没必要,通过线程自身的中断状态,就可以完美实现该功能。如果线程在调用 Object 类的 wait()、wait(long) 或 wait(long, int) 方法,或者该类的 join()、join(long)、join(long, int)、sleep(long) 或 sleep(long, int) 方法过程中受阻,则其中断状态将被清除,它还将收到一个 InterruptedException。 我们可以捕获该异常,并且做一些处理。另外,Thread.interrupted()方法是一个静态方法,它是判断当前线程的中断状态,需要注意的是,线程的中断状态会由该方法清除。换句话说,如果连续两次调用该方法,则第二次调用将返回 false(在第一次调用已清除了其中断状态之后,且第二次调用检验完中断状态前,当前线程再次中断的情况除外)。
线程让步
static void
yield()
暂停当前正在执行的线程对象,并执行其他线程
线程让步用于正在执行的线程,在某些情况下让出CPU资源,让给其它线程执行,来看一个小例子:
输出结果略,从输出结果可以看到,当某个线程(t1或者t2)执行到10次、20次、30次等时,就会马上切换到另一个线程执行,接下来再交替执行,如此往复。注意,如果存在synchronized线程同步的话,线程让步不会释放锁(监视器对象)。
线程睡眠
static void
sleep(long millis)
在指定的毫秒数内让当前正在执行的线程休眠(暂停执行)。
static void
sleep(long millis, int nanos)
在指定的毫秒数加指定的纳秒数内让当前正在执行的线程休眠(暂停执行)。
线程睡眠的过程中,如果是在synchronized线程同步内,是持有锁(监视器对象)的,也就是说,线程是关门睡觉的,别的线程进不来,来看一个小例子:
输出结果:
线程合并
void
join()
等待该线程终止。
void
join(long millis)
等待该线程终止的时间最长为
millis
毫秒。 void
join(long millis, int nanos)
等待该线程终止的时间最长为
millis
毫秒 + nanos
纳秒。线程优先级
public static final int
MAX_PRIORITY
10
public static final int
MIN_PRIORITY
1
public static final int
NORM_PRIORITY
5
我们创建线程对象后,如果不显示的设置优先级的话,默认为5。优先级可以看成一种特权,优先级高的,获取CPU调度的机会就大,优先级低的,获取CPU调度的机会就小,这个和我们现实生活很一样啊,优胜劣汰。线程优先级的示例就不写了,比较简单。wait()和sleep()区别
其实就Timer来讲就是一个调度器,而TimerTask呢只是一个实现了run方法的一个类,而具体的TimerTask需要由你自己来实现,例如这样:
- Timer timer = new Timer();
- timer.schedule(new TimerTask() {
- public void run() {
- System.out.println("abc");
- }
- }, 200000 , 1000);
这里直接实现一个TimerTask(当然,你可以实现多个TimerTask,多个TimerTask可以被一个Timer会被分配到多个Timer中被调度,后面会说到Timer的实现机制就是说内部的调度机制),然后编写run方法,20s后开始执行,每秒执行一次,当然你通过一个timer对象来操作多个timerTask,其实timerTask本身没什么意义,只是和timer集合操作的一个对象,实现它就必然有对应的run方法,以被调用,他甚至于根本不需要实现Runnable,因为这样往往混淆视听了,为什么呢?也是本文要说的重点。
在说到timer的原理时,我们先看看Timer里面的一些常见方法:
- public void schedule(TimerTask task, long delay)
这个方法是调度一个task,经过delay(ms)后开始进行调度,仅仅调度一次。
- public void schedule(TimerTask task, Date time)
在指定的时间点time上调度一次。
- public void schedule(TimerTask task, long delay, long period)
这个方法是调度一个task,在delay(ms)后开始调度,每次调度完后,最少等待period(ms)后才开始调度。
- public void schedule(TimerTask task, Date firstTime, long period)
和上一个方法类似,唯一的区别就是传入的第二个参数为第一次调度的时间。
- public void scheduleAtFixedRate(TimerTask task, long delay, long period)
调度一个task,在delay(ms)后开始调度,然后每经过period(ms)再次调度,貌似和方法:schedule是一样的,其实不然,后面你会根据源码看到,schedule在计算下一次执行的时间的时候,是通过当前时间(在任务执行前得到) + 时间片,而scheduleAtFixedRate方法是通过当前需要执行的时间(也就是计算出现在应该执行的时间)+ 时间片,前者是运行的实际时间,而后者是理论时间点,例如:schedule时间片是5s,那么理论上会在5、10、15、20这些时间片被调度,但是如果由于某些CPU征用导致未被调度,假如等到第8s才被第一次调度,那么schedule方法计算出来的下一次时间应该是第13s而不是第10s,这样有可能下次就越到20s后而被少调度一次或多次,而scheduleAtFixedRate方法就是每次理论计算出下一次需要调度的时间用以排序,若第8s被调度,那么计算出应该是第10s,所以它距离当前时间是2s,那么再调度队列排序中,会被优先调度,那么就尽量减少漏掉调度的情况。
- public void scheduleAtFixedRate(TimerTask task, Date firstTime,long period)
方法同上,唯一的区别就是第一次调度时间设置为一个Date时间,而不是当前时间的一个时间片,我们在源码中会详细说明这些内容。
接下来看源码
首先看Timer的构造方法有几种:
构造方法1:无参构造方法,简单通过Tiemer为前缀构造一个线程名称:
- public Timer() {
- this("Timer-" + serialNumber());
- }
传入是否为后台线程,如果设置为后台线程,则主线程结束后,timer自动结束,而无需使用cancel来完成对timer的结束
构造方法2:传入了是否为后台线程,后台线程当且仅当进程结束时,自动注销掉。
- public Timer(boolean isDaemon) {
- this("Timer-" + serialNumber(), isDaemon);
- }
另外两个构造方法负责传入名称和将timer启动:
- public Timer(String name, boolean isDaemon) {
- thread.setName(name);
- thread.setDaemon(isDaemon);
- thread.start();
- }
这里有一个thread,这个thread很明显是一个线程,被包装在了Timer类中,我们看下这个thread的定义是:
- private TimerThread thread = new TimerThread(queue);
而定义TimerThread部分的是:
- class TimerThread extends Thread {
看到这里知道了,Timer内部包装了一个线程,用来做独立于外部线程的调度,而TimerThread是一个default类型的,默认情况下是引用不到的,是被Timer自己所使用的。
接下来看下有那些属性
除了上面提到的thread,还有一个很重要的属性是:
- private TaskQueue queue = new TaskQueue();
看名字就知道是一个队列,队列里面可以先猜猜看是什么,那么大概应该是我要调度的任务吧,先记录下了,接下来继续向下看:
里面还有一个属性是:threadReaper,它是Object类型,只是重写了finalize方法而已,是为了垃圾回收的时候,将相应的信息回收掉,做GC的回补,也就是当timer线程由于某种原因死掉了,而未被cancel,里面的队列中的信息需要清空掉,不过我们通常是不会考虑这个方法的,所以知道java写这个方法是干什么的就行了。
接下来看调度方法的实现:
对于上面6个调度方法,我们不做一一列举,为什么等下你就知道了:
来看下方法:
- public void schedule(TimerTask task, long delay)
的源码如下:
- public void schedule(TimerTask task, long delay) {
- if (delay < 0)
- throw new IllegalArgumentException("Negative delay.");
- sched(task, System.currentTimeMillis()+delay, 0);
- }
这里调用了另一个方法,将task传入,第一个参数传入System.currentTimeMillis()+delay可见为第一次需要执行的时间的时间点了(如果传入Date,就是对象.getTime()即可,所以传入Date的几个方法就不用多说了),而第三个参数传入了0,这里可以猜下要么是时间片,要么是次数啥的,不过等会就知道是什么了;另外关于方法:sched的内容我们不着急去看他,先看下重载的方法中是如何做的
在看看方法:
public void schedule(TimerTask task, long delay,long period)
源码为:
- public void schedule(TimerTask task, long delay, long period) {
- if (delay < 0)
- throw new IllegalArgumentException("Negative delay.");
- if (period <= 0)
- throw new IllegalArgumentException("Non-positive period.");
- sched(task, System.currentTimeMillis()+delay, -period);
- }
看来也调用了方法sched来完成调度,和上面的方法唯一的调度时候的区别是增加了传入的period,而第一个传入的是0,所以确定这个参数为时间片,而不是次数,注意这个里的period加了一个负数,也就是取反,也就是我们开始传入1000,在调用sched的时候会变成-1000,其实最终阅读完源码后你会发现这个算是老外对于一种数字的理解,而并非有什么特殊的意义,所以阅读源码的时候也有这些困难所在。
最后再看个方法是:
public void scheduleAtFixedRate(TimerTasktask,long delay,long period)
源码为:
- public void scheduleAtFixedRate(TimerTask task, long delay, long period) {
- if (delay < 0)
- throw new IllegalArgumentException("Negative delay.");
- if (period <= 0)
- throw new IllegalArgumentException("Non-positive period.");
- sched(task, System.currentTimeMillis()+delay, period);
- }
唯一的区别就是在period没有取反,其实你最终阅读完源码,上面的取反没有什么特殊的意义,老外不想增加一个参数来表示scheduleAtFixedRate,而scheduleAtFixedRate和schedule的大部分逻辑代码一致,因此用了参数的范围来作为区分方法,也就是当你传入的参数不是正数的时候,你调用schedule方法正好是得到scheduleAtFixedRate的功能,而调用scheduleAtFixedRate方法的时候得到的正好是schedule方法的功能,呵呵,这些讨论没什么意义,讨论实质和重点:
来看sched方法的实现体:
- private void sched(TimerTask task, long time, long period) {
- if (time < 0)
- throw new IllegalArgumentException("Illegal execution time.");
- synchronized(queue) {
- if (!thread.newTasksMayBeScheduled)
- throw new IllegalStateException("Timer already cancelled.");
- synchronized(task.lock) {
- if (task.state != TimerTask.VIRGIN)
- throw new IllegalStateException(
- "Task already scheduled or cancelled");
- task.nextExecutionTime = time;
- task.period = period;
- task.state = TimerTask.SCHEDULED;
- }
- queue.add(task);
- if (queue.getMin() == task)
- queue.notify();
- }
- }
queue为一个队列,我们先不看他数据结构,看到他在做这个操作的时候,发生了同步,所以在timer级别,这个是线程安全的,最后将task相关的参数赋值,主要包含nextExecutionTime(下一次执行时间),period(时间片),state(状态),然后将它放入queue队列中,做一次notify操作,为什么要做notify操作呢?看了后面的代码你就知道了。
简言之,这里就是讲task放入队列queue的过程,此时,你可能对queue的结构有些兴趣,那么我们先来看看queue属性的结构TaskQueue:
- class TaskQueue {
- private TimerTask[] queue = new TimerTask[128];
- private int size = 0;
可见,TaskQueue的结构很简单,为一个数组,加一个size,有点像ArrayList,是不是长度就128呢,当然不是,ArrayList可以扩容,它可以,只是会造成内存拷贝而已,所以一个Timer来讲,只要内部的task个数不超过128是不会造成扩容的;内部提供了add(TimerTask)、size()、getMin()、get(int)、removeMin()、quickRemove(int)、rescheduleMin(long newTime)、isEmpty()、clear()、fixUp()、fixDown()、heapify();
这里面的方法大概意思是:
add(TimerTaskt)为增加一个任务
size()任务队列的长度
getMin()获取当前排序后最近需要执行的一个任务,下标为1,队列头部0是不做任何操作的。
get(inti)获取指定下标的数据,当然包括下标0.
removeMin()为删除当前最近执行的任务,也就是第一个元素,通常只调度一次的任务,在执行完后,调用此方法,就可以将TimerTask从队列中移除。
quickRmove(inti)删除指定的元素,一般来说是不会调用这个方法的,这个方法只有在Timer发生purge的时候,并且当对应的TimerTask调用了cancel方法的时候,才会被调用这个方法,也就是取消某个TimerTask,然后就会从队列中移除(注意如果任务在执行中是,还是仍然在执行中的,虽然在队列中被移除了),还有就是这个cancel方法并不是Timer的cancel方法而是TimerTask,一个是调度器的,一个是单个任务的,最后注意,这个quickRmove完成后,是将队列最后一个元素补充到这个位置,所以此时会造成顺序不一致的问题,后面会有方法进行回补。
rescheduleMin(long newTime)是重新设置当前执行的任务的下一次执行时间,并在队列中将其从新排序到合适的位置,而调用的是后面说的fixDown方法。
对于fixUp和fixDown方法来讲,前者是当新增一个task的时候,首先将元素放在队列的尾部,然后向前找是否有比自己还要晚执行的任务,如果有,就将两个任务的顺序进行交换一下。而fixDown正好相反,执行完第一个任务后,需要加上一个时间片得到下一次执行时间,从而需要将其顺序与后面的任务进行对比下。
其次可以看下fixDown的细节为:
- private void fixDown(int k) {
- int j;
- while ((j = k << 1) <= size && j > 0) {
- if (j < size &&
- queue[j].nextExecutionTime > queue[j+1].nextExecutionTime)
- j++; // j indexes smallest kid
- if (queue[k].nextExecutionTime <= queue[j].nextExecutionTime)
- break;
- TimerTask tmp = queue[j]; queue[j] = queue[k]; queue[k] = tmp;
- k = j;
- }
- }
这种方式并非排序,而是找到一个合适的位置来交换,因为并不是通过队列逐个找的,而是每次移动一个二进制为,例如传入1的时候,接下来就是2、4、8、16这些位置,找到合适的位置放下即可,顺序未必是完全有序的,它只需要看到距离调度部分的越近的是有序性越强的时候就可以了,这样即可以保证一定的顺序性,达到较好的性能。
最后一个方法是heapify,其实就是将队列的后半截,全部做一次fixeDown的操作,这个操作主要是为了回补quickRemove方法,当大量的quickRmove后,顺序被打乱后,此时将一半的区域做一次非常简单的排序即可。
这些方法我们不在说源码了,只需要知道它提供了类似于ArrayList的东西来管理,内部有很多排序之类的处理,我们继续回到Timer,里面还有两个方法是:cancel()和方法purge()方法,其实就cancel方法来讲,一个取消操作,在测试中你会发现,如果一旦执行了这个方法timer就会结束掉,看下源码是什么呢:
- public void cancel() {
- synchronized(queue) {
- thread.newTasksMayBeScheduled = false;
- queue.clear();
- queue.notify(); // In case queue was already empty.
- }
- }
貌似仅仅将队列清空掉,然后设置了newTasksMayBeScheduled状态为false,最后让队列也调用了下notify操作,但是没有任何地方让线程结束掉,那么就要回到我们开始说的Timer中包含的thread为:TimerThread类了,在看这个类之前,再看下Timer中最后一个purge()类,当你对很多Task做了cancel操作后,此时通过调用purge方法实现对这些cancel掉的类空间的回收,上面已经提到,此时会造成顺序混乱,所以需要调用队里的heapify方法来完成顺序的重排,源码如下:
- public int purge() {
- int result = 0;
- synchronized(queue) {
- for (int i = queue.size(); i > 0; i--) {
- if (queue.get(i).state == TimerTask.CANCELLED) {
- queue.quickRemove(i);
- result++;
- }
- }
- if (result != 0)
- queue.heapify();
- }
- return result;
- }
那么调度呢,是如何调度的呢,那些notify,和清空队列是如何做到的呢?我们就要看看TimerThread类了,内部有一个属性是:newTasksMayBeScheduled,也就是我们开始所提及的那个参数在cancel的时候会被设置为false。
另一个属性定义了
private TaskQueue queue;
也就是我们所调用的queue了,这下联通了吧,不过这里是queue是通过构造方法传入的,传入后赋值用以操作,很明显是Timer传递给这个线程的,我们知道它是一个线程,所以执行的中心自然是run方法了,所以看下run方法的body部分是:
- public void run() {
- try {
- mainLoop();
- } finally {
- synchronized(queue) {
- newTasksMayBeScheduled = false;
- queue.clear(); // Eliminate obsolete references
- }
- }
- }
try很简单,就一个mainLoop,看名字知道是主循环程序,finally中也就是必然执行的程序为将参数为为false,并将队列清空掉。
那么最核心的就是mainLoop了,是的,看懂了mainLoop一切都懂了:
- private void mainLoop() {
- while (true) {
- try {
- TimerTask task;
- boolean taskFired;
- synchronized(queue) {
- // Wait for queue to become non-empty
- while (queue.isEmpty() && newTasksMayBeScheduled)
- queue.wait();
- if (queue.isEmpty())
- break; // Queue is empty and will forever remain; die
- // Queue nonempty; look at first evt and do the right thing
- long currentTime, executionTime;
- task = queue.getMin();
- synchronized(task.lock) {
- if (task.state == TimerTask.CANCELLED) {
- queue.removeMin();
- continue; // No action required, poll queue again
- }
- currentTime = System.currentTimeMillis();
- executionTime = task.nextExecutionTime;
- if (taskFired = (executionTime<=currentTime)) {
- if (task.period == 0) { // Non-repeating, remove
- queue.removeMin();
- task.state = TimerTask.EXECUTED;
- } else { // Repeating task, reschedule
- queue.rescheduleMin(
- task.period<0 ? currentTime - task.period
- : executionTime + task.period);
- }
- }
- }
- if (!taskFired) // Task hasn't yet fired; wait
- queue.wait(executionTime - currentTime);
- }
- if (taskFired) // Task fired; run it, holding no locks
- task.run();
- } catch(InterruptedException e) {
- }
- }
- }
可以发现这个timer是一个死循环程序,除非遇到不能捕获的异常或break才会跳出,首先注意这段代码:
while (queue.isEmpty() &&newTasksMayBeScheduled)
queue.wait();
循环体为循环过程中,条件为queue为空且newTasksMayBeScheduled状态为true,可以看到这个状态其关键作用,也就是跳出循环的条件就是要么队列不为空,要么是newTasksMayBeScheduled状态设置为false才会跳出,而wait就是在等待其他地方对queue发生notify操作,从上面的代码中可以发现,当发生add、cancel以及在threadReaper调用finalize方法的时候会被调用,第三个我们基本可以不考虑其实发生add的时候也就是当队列还是空的时候,发生add使得队列不为空就跳出循环,而cancel是设置了状态,否则不会进入这个循环,那么看下面的代码:
if (queue.isEmpty())
break;
当跳出上面的循环后,如果是设置了newTasksMayBeScheduled状态为false跳出,也就是调用了cancel,那么queue就是空的,此时就直接跳出外部的死循环,所以cancel就是这样实现的,如果下面的任务还在跑还没运行到这里来,cancel是不起作用的。
接下来是获取一个当前系统时间和上次预计的执行时间,如果预计执行的时间小于当前系统时间,那么就需要执行,此时判定时间片是否为0,如果为0,则调用removeMin方法将其移除,否则将task通过rescheduleMin设置最新时间并排序:
- currentTime = System.currentTimeMillis();
- executionTime = task.nextExecutionTime;
- if (taskFired = (executionTime<=currentTime)) {
- if (task.period == 0) { // Non-repeating, remove
- queue.removeMin();
- task.state = TimerTask.EXECUTED;
- } else { // Repeating task, reschedule
- queue.rescheduleMin(
- task.period<0 ? currentTime - task.period
- : executionTime + task.period);
- }
- }
这里可以看到,period为负数的时候,就会被认为是按照按照当前系统时间+一个时间片来计算下一次时间,就是前面说的schedule和scheduleAtFixedRate的区别了,其实内部是通过正负数来判定的,也许java是不想增加参数,而又想增加程序的可读性,才这样做,其实通过正负判定是有些诡异的,也就是你如果在schedule方法传入负数达到的功能和scheduleAtFixedRate的功能是一样的,相反在scheduleAtFixedRate方法中传入负数功能和schedule方法是一样的。
同时你可以看到period为0,就是只执行一次,所以时间片正负0都用上了,呵呵,然后再看看mainLoop接下来的部分:
if (!taskFired)// Taskhasn't yet fired; wait
queue.wait(executionTime- currentTime);
这里是如果任务执行时间还未到,就等待一段时间,当然这个等待很可能会被其他的线程操作add和cancel的时候被唤醒,因为内部有notify方法,所以这个时间并不是完全准确,在这里大多数情况下是考虑Timer内部的task信息是稳定的,cancel方法唤醒的话是另一回事。
最后:
if (taskFired) // Task fired; run it, holding no locks
task.run();
如果线程需要执行,那么调用它的run方法,而并非启动一个新的线程或从线程池中获取一个线程来执行,所以TimerTask的run方法并不是多线程的run方法,虽然实现了Runnable,但是仅仅是为了表示它是可执行的,并不代表它必须通过线程的方式来执行的。
回过头来再看看:
Timer和TimerTask的简单组合是多线程的嘛?不是,一个Timer内部包装了“一个Thread”和“一个Task”队列,这个队列按照一定的方式将任务排队处理,包含的线程在Timer的构造方法调用时被启动,这个Thread的run方法无限循环这个Task队列,若队列为空且没发生cancel操作,此时会一直等待,如果等待完成后,队列还是为空,则认为发生了cancel从而跳出死循环,结束任务;循环中如果发现任务需要执行的时间小于系统时间,则需要执行,那么根据任务的时间片从新计算下次执行时间,若时间片为0代表只执行一次,则直接移除队列即可。
但是是否能实现多线程呢?可以,任何东西是否是多线程完全看个人意愿,多个Timer自然就是多线程的,每个Timer都有自己的线程处理逻辑,当然Timer从这里来看并不是很适合很多任务在短时间内的快速调度,至少不是很适合同一个timer上挂很多任务,在多线程的领域中我们更多是使用多线程中的:
Executors.newScheduledThreadPool
来完成对调度队列中的线程池的处理,内部通过new ScheduledThreadPoolExecutor来创建线程池的Executor的创建,当然也可以调用:
Executors.unconfigurableScheduledExecutorService
方法来创建一个DelegatedScheduledExecutorService其实这个类就是包装了下下scheduleExecutor,也就是这只是一个壳,英文理解就是被委派的意思,被托管的意思。
线程池
自JDK5之后,Java推出了一个并发包,java.util.concurrent,在Java开发中,我们接触到了好多池的技术,String类的对象池、Integer的共享池、连接数据库的连接池、Struts1.3的对象池等等,池的最终目的都是节约资源,以更小的开销做更多的事情,从而提高性能。
我们的web项目都是部署在服务器上,浏览器端的每一个request就是一个线程,那么服务器需要并发的处理多个请求,就需要线程池技术,下面来看一下Java并发包下如何创建线程池。
1. 创建一个可重用固定线程集合的线程池,以共享的无界队列方式来运行这些线程。
- ExecutorService threadPool = Executors.newFixedThreadPool(3);// 创建可以容纳3个线程的线程池
2. 创建一个可根据需要创建新线程的线程池,但是在以前构造的线程可用时将重用它们。
- ExecutorService threadPool = Executors.newCachedThreadPool();// 线程池的大小会根据执行的任务数动态分配
3. 创建一个使用单个 worker 线程的 Executor,以无界队列方式来运行该线程。
- ExecutorService threadPool = Executors.newSingleThreadExecutor();// 创建单个线程的线程池,如果当前线程在执行任务时突然中断,则会创建一个新的线程替代它继续执行任务
4. 创建一个可安排在给定延迟后运行命令或者定期地执行的线程池。
- ScheduledExecutorService threadPool = Executors.newScheduledThreadPool(3);// 效果类似于Timer定时器
每种线程池都有不同的使用场景,下面看一下这四种线程池使用起来有什么不同。
1. FixedThreadPool
- import java.util.concurrent.ExecutorService;
- import java.util.concurrent.Executors;
- public class ThreadPoolTest {
- public static void main(String[] args) {
- ExecutorService threadPool = Executors.newFixedThreadPool(3);
- for(int i = 1; i < 5; i++) {
- final int taskID = i;
- threadPool.execute(new Runnable() {
- public void run() {
- for(int i = 1; i < 5; i++) {
- try {
- Thread.sleep(20);// 为了测试出效果,让每次任务执行都需要一定时间
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- System.out.println("第" + taskID + "次任务的第" + i + "次执行");
- }
- }
- });
- }
- threadPool.shutdown();// 任务执行完毕,关闭线程池
- }
- }
输出结果:
- 第1次任务的第1次执行
- 第2次任务的第1次执行
- 第3次任务的第1次执行
- 第2次任务的第2次执行
- 第3次任务的第2次执行
- 第1次任务的第2次执行
- 第3次任务的第3次执行
- 第1次任务的第3次执行
- 第2次任务的第3次执行
- 第3次任务的第4次执行
- 第2次任务的第4次执行
- 第1次任务的第4次执行
- 第4次任务的第1次执行
- 第4次任务的第2次执行
- 第4次任务的第3次执行
- 第4次任务的第4次执行
上段代码中,创建了一个固定大小的线程池,容量为3,然后循环执行了4个任务,由输出结果可以看到,前3个任务首先执行完,然后空闲下来的线程去执行第4个任务,在FixedThreadPool中,有一个固定大小的池,如果当前需要执行的任务超过了池大小,那么多于的任务等待状态,直到有空闲下来的线程执行任务,而当执行的任务小于池大小,空闲的线程也不会去销毁。
2. CachedThreadPool
上段代码其它地方不变,将newFixedThreadPool方法换成newCachedThreadPool方法。
输出结果:
- 第3次任务的第1次执行
- 第4次任务的第1次执行
- 第1次任务的第1次执行
- 第2次任务的第1次执行
- 第4次任务的第2次执行
- 第3次任务的第2次执行
- 第2次任务的第2次执行
- 第1次任务的第2次执行
- 第2次任务的第3次执行
- 第3次任务的第3次执行
- 第1次任务的第3次执行
- 第4次任务的第3次执行
- 第2次任务的第4次执行
- 第4次任务的第4次执行
- 第3次任务的第4次执行
- 第1次任务的第4次执行
可见,4个任务是交替执行的,CachedThreadPool会创建一个缓存区,将初始化的线程缓存起来,如果线程有可用的,就使用之前创建好的线程,如果没有可用的,就新创建线程,终止并且从缓存中移除已有60秒未被使用的线程。
3. SingleThreadExecutor
上段代码其它地方不变,将newFixedThreadPool方法换成newSingleThreadExecutor方法。
输出结果:
- 第1次任务的第1次执行
- 第1次任务的第2次执行
- 第1次任务的第3次执行
- 第1次任务的第4次执行
- 第2次任务的第1次执行
- 第2次任务的第2次执行
- 第2次任务的第3次执行
- 第2次任务的第4次执行
- 第3次任务的第1次执行
- 第3次任务的第2次执行
- 第3次任务的第3次执行
- 第3次任务的第4次执行
- 第4次任务的第1次执行
- 第4次任务的第2次执行
- 第4次任务的第3次执行
- 第4次任务的第4次执行
4个任务是顺序执行的,SingleThreadExecutor得到的是一个单个的线程,这个线程会保证你的任务执行完成,如果当前线程意外终止,会创建一个新线程继续执行任务,这和我们直接创建线程不同,也和newFixedThreadPool(1)不同。
4.ScheduledThreadPool
- import java.util.concurrent.ScheduledExecutorService;
- import java.util.concurrent.TimeUnit;
- public class ThreadPoolTest {
- public static void main(String[] args) {
- ScheduledExecutorService schedulePool = Executors.newScheduledThreadPool(1);
- // 5秒后执行任务
- schedulePool.schedule(new Runnable() {
- public void run() {
- System.out.println("爆炸");
- }
- }, 5, TimeUnit.SECONDS);
- // 5秒后执行任务,以后每2秒执行一次
- schedulePool.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- System.out.println("爆炸");
- }
- }, 5, 2, TimeUnit.SECONDS);
- }
- }
ScheduledThreadPool可以定时的或延时的执行任务。
Java的并发包很强大,上面所说只是入门,随着学习深入,会有更多记录在博客里。
Callable和Future
Callable接口类似于Runnable,从名字就可以看出来了,但是Runnable不会返回结果,并且无法抛出返回结果的异常,而Callable功能更强大一些,被线程执行后,可以返回值,这个返回值可以被Future拿到,也就是说,Future可以拿到异步执行任务的返回值,下面来看一个简单的例子:
FutureTask实现了两个接口,Runnable和Future,所以它既可以作为Runnable被线程执行,又可以作为Future得到Callable的返回值,那么这个组合的使用有什么好处呢?假设有一个很耗时的返回值需要计算,并且这个返回值不是立刻需要的话,那么就可以使用这个组合,用另一个线程去计算返回值,而当前线程在使用这个返回值之前可以做其它的操作,等到需要这个返回值时,再通过Future得到,岂不美哉!这里有一个Future模式的介绍:http://openhome.cc/Gossip/DesignPattern/FuturePattern.htm。
下面来看另一种方式使用Callable和Future,通过ExecutorService的submit方法执行Callable,并返回Future,代码如下:
代码是不是简化了很多,ExecutorService继承自Executor,它的目的是为我们管理Thread对象,从而简化并发编程,Executor使我们无需显示的去管理线程的生命周期,是JDK 5之后启动任务的首选方式。
执行多个带返回值的任务,并取得多个返回值,代码如下:
其实也可以不使用CompletionService,可以先创建一个装Future类型的集合,用Executor提交的任务返回值添加到集合中,最后遍历集合取出数据,代码略。
锁对象Lock-同步问题更完美的处理方式
Lock是java.util.concurrent.locks包下的接口,Lock 实现提供了比使用synchronized 方法和语句可获得的更广泛的锁定操作,它能以更优雅的方式处理线程同步问题,我们拿Java线程(二)中的一个例子简单的实现一下和sychronized一样的效果,代码如下:
这样就实现了和sychronized一样的同步效果,需要注意的是,用sychronized修饰的方法或者语句块在代码执行完之后锁自动释放,而用Lock需要我们手动释放锁,所以为了保证锁最终被释放(发生异常情况),要把互斥区放在try内,释放锁放在finally内。
如果说这就是Lock,那么它不能成为同步问题更完美的处理方式,下面要介绍的是读写锁(ReadWriteLock),我们会有一种需求,在对数据进行读写的时候,为了保证数据的一致性和完整性,需要读和写是互斥的,写和写是互斥的,但是读和读是不需要互斥的,这样读和读不互斥性能更高些,来看一下不考虑互斥情况的代码原型:
部分输出结果:
我们要实现写入和写入互斥,读取和写入互斥,读取和读取互斥,在set和get方法加入sychronized修饰符:
部分输出结果:
我们发现,虽然写入和写入互斥了,读取和写入也互斥了,但是读取和读取之间也互斥了,不能并发执行,效率较低,用读写锁实现代码如下:
部分输出结果:
从结果可以看出实现了我们的需求,这只是锁的基本用法,锁的机制还需要继续深入学习。
接近一周没更新《Java线程》专栏了,主要是这周工作上比较忙,生活上也比较忙,呵呵,进入正题,上一篇讲述了并发包下的Lock,Lock可以更好的解决线程同步问题,使之更面向对象,并且ReadWriteLock在处理同步时更强大,那么同样,线程间仅仅互斥是不够的,还需要通信,本篇的内容是基于上篇之上,使用Lock如何处理线程通信。
那么引入本篇的主角,Condition,Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象,以便通过将这些对象与任意 Lock 实现组合使用,为每个对象提供多个等待 set (wait-set)。其中,Lock 替代了 synchronized 方法和语句的使用,Condition 替代了 Object 监视器方法的使用。下面将之前写过的一个线程通信的例子替换成用Condition实现(Java线程(三)),代码如下:
在Condition中,用await()替换wait(),用signal()替换notify(),用signalAll()替换notifyAll(),传统线程的通信方式,Condition都可以实现,这里注意,Condition是被绑定到Lock上的,要创建一个Lock的Condition必须用newCondition()方法。
这样看来,Condition和传统的线程通信没什么区别,Condition的强大之处在于它可以为多个线程间建立不同的Condition,下面引入API中的一段代码,加以说明。
这是一个处于多线程工作环境下的缓存区,缓存区提供了两个方法,put和take,put是存数据,take是取数据,内部有个缓存队列,具体变量和方法说明见代码,这个缓存区类实现的功能:有多个线程往里面存数据和从里面取数据,其缓存队列(先进先出后进后出)能缓存的最大数值是100,多个线程间是互斥的,当缓存队列中存储的值达到100时,将写线程阻塞,并唤醒读线程,当缓存队列中存储的值为0时,将读线程阻塞,并唤醒写线程,下面分析一下代码的执行过程:
1. 一个写线程执行,调用put方法;
2. 判断count是否为100,显然没有100;
3. 继续执行,存入值;
4. 判断当前写入的索引位置++后,是否和100相等,相等将写入索引值变为0,并将count+1;
5. 仅唤醒读线程阻塞队列中的一个;
6. 一个读线程执行,调用take方法;
7. ……
8. 仅唤醒写线程阻塞队列中的一个。
这就是多个Condition的强大之处,假设缓存队列中已经存满,那么阻塞的肯定是写线程,唤醒的肯定是读线程,相反,阻塞的肯定是读线程,唤醒的肯定是写线程,那么假设只有一个Condition会有什么效果呢,缓存队列中已经存满,这个Lock不知道唤醒的是读线程还是写线程了,如果唤醒的是读线程,皆大欢喜,如果唤醒的是写线程,那么线程刚被唤醒,又被阻塞了,这时又去唤醒,这样就浪费了很多时间。
阻塞队列BlockingQueue
这一段时间我的工作主要是改进公司的调度器,调度器调度线程池执行任务,生产者生产任务,消费者消费任务,那么这时就需要一个任务队列,生产者向队列里插入任务,消费者从队列里提取任务执行,调度器里是通过BlockingQueue实现的队列,随后小查一下,下面看看BlockingQueue的原理及其方法。
BlockingQueue最终会有四种状况,抛出异常、返回特殊值、阻塞、超时,下表总结了这些方法:
抛出异常特殊值阻塞超时插入
add(e)
offer(e)
put(e)
offer(e, time, unit)
移除remove()
poll()
take()
poll(time, unit)
检查element()
peek()
不可用不可用
BlockingQueue是个接口,有如下实现类:
1. ArrayBlockQueue:一个由数组支持的有界阻塞队列。此队列按 FIFO(先进先出)原则对元素进行排序。创建其对象必须明确大小,像数组一样。
2. LinkedBlockQueue:一个可改变大小的阻塞队列。此队列按 FIFO(先进先出)原则对元素进行排序。创建其对象如果没有明确大小,默认值是Integer.MAX_VALUE。链接队列的吞吐量通常要高于基于数组的队列,但是在大多数并发应用程序中,其可预知的性能要低。
3. PriorityBlockingQueue:类似于LinkedBlockingQueue,但其所含对象的排序不是FIFO,而是依据对象的自然排序顺序或者是构造函数所带的Comparator决定的顺序。
4. SynchronousQueue:同步队列。同步队列没有任何容量,每个插入必须等待另一个线程移除,反之亦然。
下面使用ArrayBlockQueue来实现之前实现过的生产者消/费者模式,代码如下:
执行结果:
从结果看,启动10个放鸡蛋线程和10个取鸡蛋线程,前5个放入鸡蛋的线程成功执行,到第6个,发现盘子满了,阻塞住,这时切换到取鸡蛋线程执行,成功实现了生产者/消费者模式。java.util.concurrent包是个强大的包!
Java线程(篇外篇):线程本地变量ThreadLocal
ThreadLocal存放的值是线程内共享的,线程间互斥的,主要用于线程内共享一些数据,避免通过参数来传递,这样处理后,能够优雅的解决一些实际问题,比如Hibernate中的OpenSessionInView,就是使用ThreadLocal保存Session对象,还有我们经常用ThreadLocal存放Connection,代码如:
这样处理的好处:
- 统一管理Connection;
- 不需要显示传参Connection,代码更优雅;
- 降低耦合性。
ThreadLocal有四个方法,分别为:
initialValue
protected T initialValue()
get()
方法访问变量的时候。如果线程先于 get 方法调用 set(T)
方法,则不会在线程中再调用 initialValue 方法。该实现只返回 null;如果程序员希望将线程局部变量初始化为 null 以外的某个值,则必须为 ThreadLocal 创建子类,并重写此方法。通常,将使用匿名内部类。initialValue 的典型实现将调用一个适当的构造方法,并返回新构造的对象。
get
public T get()
set
public void set(T value)
initialValue()
方法来设置线程局部变量的值。
value
- 存储在此线程局部变量的当前线程副本中的值。remove
public void remove()
很多人对ThreadLocal存在一定的误解,说ThreadLocal中有一个全局的Map,set时执行map.put(Thread.currentThread(), value),get和remove时也同理,但SUN的大师们是否是如此实现的,我们只能去看源码了。
set方法:
这里注意,ThreadLocal中是有一个Map,但这个Map不是我们平时使用的Map,而是ThreadLocalMap,ThreadLocalMap是ThreadLocal的一个内部类,不对外使用的。当使用ThreadLocal存值时,首先是获取到当前线程对象,然后获取到当前线程本地变量Map,最后将当前使用的ThreadLocal和传入的值放到Map中,也就是说ThreadLocalMap中存的值是[ThreadLocal对象, 存放的值],这样做的好处是,每个线程都对应一个本地变量的Map,所以一个线程可以存在多个线程本地变量。
get方法:
有了之前set方法的分析,get方法也同理,需要说明的是,如果没有进行过set操作,那从ThreadLocalMap中拿到的值就是null,这时get方法会返回初始值,也就是调用initialValue()方法,ThreadLocal中这个方法默认返回null。当我们有需要第一次get时就能得到一个值时,可以继承ThreadLocal,并且覆盖initialValue()方法。
- Java线程:什么是线程
- Java线程:线程池
- java线程--线程退出
- JAVA-线程/线程锁
- Java线程:什么是线程
- Java线程:线程中断
- Java线程:线程状态
- Java线程: 线程调度
- Java线程:线程交互
- java--线程--线程池
- java 线程
- Java线程
- java线程
- java线程
- Java线程
- Java线程
- java线程
- JAVA 线程
- ios界面跳转总结(一)
- 关于建树以及建单链表时要使用二重指针的原因
- iOS: AFNetworking的简单封装和图片上传
- [leetcode]Intersection of Two Linked Lists寻找两链表的公共节点
- [LeetCode 147]Insertion Sort List
- java线程
- 20150325
- 如何实现servlet的单线程模式
- Android Service简介
- 运行struts2程序时核心加载包struts2-core-2.3.15.1.jar报严重错误
- RFID系统组成及其功能
- java
- 关于对象及构造函数语义学
- samba实现简单的linux与window文件共享