线程间通信：由于多线程共享地址空间和数据空间，所以多个线程间的通信是一个线程的数据可以直接提供给其他线程使用，而不必通过操作系统（也就是内核的调度）。
进程间的通信则不同，它的数据空间的独立性决定了它的通信相对比较复杂，需要通过操作系统。以前进程间的通信只能是单机版的，现在操作系统都继承了基于套接字（socket）的进程间的通信机制。这样进程间的通信就不局限于单台计算机了，实现了网络通信。线程通信主要分为以下几个部分，下面通过生活中图书馆借书的例子简单讲解以下：
通过共享对象通信
加入图书馆只有一本《java并发编程实战》，小A早上的时候把这本书给借走了，然后下午小B去图书馆去找这本书，这时候小A和小B是两个线程，《java并发编程实战》就是共享对象（类似于多线程中的全局变量的资源），小B发现这本书已经被借走了，所以就回去等了几天，几天后，小B又去图书馆发现这本书被还回来了，就把书借走了，这就是通过共享对象进行通信。
忙等待
由于快要BAT实习生招聘了，所以小B非常想看这本书，所以小B就每隔一个小时(while循环)就去看看这本书有没有被还回来了，这样虽然比较耗费处理器资源，但是只要书一旦被还回来，小B就可以马上知道。
wait() notify() notifyAll()
由于图书馆隔着宿舍比较近，所以小B发现每隔一个小时就去图书馆身体有点吃不消，不过很快，学校的图书馆系统增加了短信提醒功能(notify())，所以小B可以一边睡觉一边等短信。
丢失的信号
图书馆系统是这么设计的，当有一本书被还回来的时候，就会给等待者发短信，但是短信只能发送一次，如果没有等待者，短信也会发出（只不过这个时候没有没有接受者），问题出现了，因为短信只会发一次，当书被还回来的时候，没有人等待借书，他会发一条空短信，但是之后有等待借此本书的同学永远也不会再收到短信，导致这些同学会无休止的等待。为了解决这个问题，我们要进入等待状态的时候先打电话问问图书馆阿姨是否需要继续等待。
假唤醒
图书馆系统有一个bug，会是不是给用户发送错误短信，我们很听话，收到短信就会去图书馆借书，但是到达图书馆后发现书根本就没有被还回来，然后接着做其他的事情。
线程间的通信方式
#锁机制：包括互斥锁、条件变量、读写锁
*互斥锁提供了以排他方式防止数据结构被并发修改的方法。
*读写锁允许多个线程同时读共享数据，而对写操作是互斥的。
*条件变量可以以原子的方式阻塞进程，直到某个特定条件为真为止。对条件的测试是在互斥锁的保护下进行的。条件变量始终与互斥锁一起使用。
#信号量机制(Semaphore)：包括无名线程信号量和命名线程信号量
#信号机制(Signal)：类似进程间的信号处理
线程间的通信目的主要是用于线程同步，所以线程没有像进程通信中的用于数据交换的通信机制。
我觉得我对线程通信的理解还是不够彻底，下面分享几段代码，帮助理解：
①同步
这里讲的同步是指多个线程通过synchronized关键字这种方式来实现线程间的通信。
参考示例：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
public class MyObject { synchronized public void methodA() { //do something.... } synchronized public void methodB() { //do some other thing }}public class ThreadA extends Thread { private MyObject object; //省略构造方法 @Override public void run() { super.run(); object.methodA(); }}public class ThreadB extends Thread { private MyObject object; //省略构造方法 @Override public void run() { super.run(); object.methodB(); }}public class Run { public static void main(String[] args) { MyObject object = new MyObject(); //线程A与线程B 持有的是同一个对象:object ThreadA a = new ThreadA(object); ThreadB b = new ThreadB(object); a.start(); b.start(); }} |
由于线程A和线程B持有同一个MyObject类的对象object，尽管这两个线程需要调用不同的方法，但是它们是同步执行的，比如：线程B需要等待线程A执行完了methodA()方法之后，它才能执行methodB()方法。这样，线程A和线程B就实现了通信。
这种方式，本质上就是“共享内存”式的通信。多个线程需要访问同一个共享变量，谁拿到了锁（获得了访问权限），谁就可以执行。
②while轮询的方式
代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
import java.util.ArrayList;import java.util.List;public class MyList { private List<String> list = new ArrayList<String>(); public void add() { list.add("elements"); } public int size() { return list.size(); }}import mylist.MyList;public class ThreadA extends Thread { private MyList list; public ThreadA(MyList list) { super(); this.list = list; } @Override public void run() { try { for (int i = 0; i < 10; i++) { list.add(); System.out.println("添加了" + (i + 1) + "个元素"); Thread.sleep(1000); } } catch (InterruptedException e) { e.printStackTrace(); } }}import mylist.MyList;public class ThreadB extends Thread { private MyList list; public ThreadB(MyList list) { super(); this.list = list; } @Override public void run() { try { while (true) { if (list.size() == 5) { System.out.println("==5, 线程b准备退出了"); throw new InterruptedException(); } } } catch (InterruptedException e) { e.printStackTrace(); } }}import mylist.MyList;import extthread.ThreadA;import extthread.ThreadB;public class Test { public static void main(String[] args) { MyList service = new MyList(); ThreadA a = new ThreadA(service); a.setName("A"); a.start(); ThreadB b = new ThreadB(service); b.setName("B"); b.start(); }} |
在这种方式下，线程A不断地改变条件，线程ThreadB不停地通过while语句检测这个条件(list.size()==5)是否成立 ，从而实现了线程间的通信。但是这种方式会浪费CPU资源。之所以说它浪费资源，是因为JVM调度器将CPU交给线程B执行时，它没做啥“有用”的工作，只是在不断地测试 某个条件是否成立。就类似于现实生活中，某个人一直看着手机屏幕是否有电话来了，而不是： 在干别的事情，当有电话来时，响铃通知TA电话来了。关于线程的轮询的影响
③wait/notify机制
代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
import java.util.ArrayList;import java.util.List;public class MyList { private static List<String> list = new ArrayList<String>(); public static void add() { list.add("anyString"); } public static int size() { return list.size(); }}public class ThreadA extends Thread { private Object lock; public ThreadA(Object lock) { super(); this.lock = lock; } @Override public void run() { try { synchronized (lock) { if (MyList.size() != 5) { System.out.println("wait begin " + System.currentTimeMillis()); lock.wait(); System.out.println("wait end " + System.currentTimeMillis()); } } } catch (InterruptedException e) { e.printStackTrace(); } }}public class ThreadB extends Thread { private Object lock; public ThreadB(Object lock) { super(); this.lock = lock; } @Override public void run() { try { synchronized (lock) { for (int i = 0; i < 10; i++) { MyList.add(); if (MyList.size() == 5) { lock.notify(); System.out.println("已经发出了通知"); } System.out.println("添加了" + (i + 1) + "个元素!"); Thread.sleep(1000); } } } catch (InterruptedException e) { e.printStackTrace(); } }}public class Run { public static void main(String[] args) { try { Object lock = new Object(); ThreadA a = new ThreadA(lock); a.start(); Thread.sleep(50); ThreadB b = new ThreadB(lock); b.start(); } catch (InterruptedException e) { e.printStackTrace(); } }} |
线程A要等待某个条件满足时(list.size()==5)，才执行操作。线程B则向list中添加元素，改变list的size。
A,B之间如何通信的呢？也就是说，线程A如何知道list.size()已经为5了呢？
这里用到了Object类的wait()和notify()方法。
当条件未满足时(list.size()!=5)，线程A调用wait()放弃CPU，并进入阻塞状态。---不像②while轮询那样占用CPU
当条件满足时，线程B调用notify()通知线程A，所谓通知线程A，就是唤醒线程A，并让它进入可运行状态。
这种方式的一个好处就是CPU的利用率提高了。
但是也有一些缺点：比如，线程B先执行，一下子添加了5个元素并调用了notify()发送了通知，而此时线程A还执行；当线程A执行并调用wait()时，那它永远就不可能被唤醒了。因为，线程B已经发了通知了，以后不再发通知了。这说明：通知过早，会打乱程序的执行逻辑。
④管道通信就是使用java.io.PipedInputStream和java.io.PipedOutputStream进行通信
具体就不介绍了。分布式系统中说的两种通信机制：共享内存机制和消息通信机制。感觉前面的①中的synchronized关键字和②中的while轮询“属于”共享内存机制，由于是轮询的条件使用了volatile关键字修饰时，这就表示它们通过判断这个“共享的条件变量“是否改变了，来实现进程间的交流。
而管道通信，更像消息传递机制，也就是说：通过管道，将一个线程中的消息发送给另一个。
总结
以上就是本文关于java线程间通信的通俗解释的全部内容，希望对大家有所帮助。如有不足之处，欢迎留言指出。
原文链接：http://blog.csdn.net/guang09080908/article/details/46956191
