「java阻塞原理」java中阻塞和非阻塞

今天给各位分享java阻塞原理的知识，其中也会对java中阻塞和非阻塞进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、java socket getinputstream 阻塞
• 2、java的monitor机制中,为什么阻塞队列用list等待队列用set
• 3、JAVA是什么意思？讲的详细一点~~~是手机软件吗？
• 4、Java 多线程 资源冲突

java socket getinputstream 阻塞

客户端的输出流和服务器端的输入流是一对，客户端的输入流和服务器端的输出流又是一对，他们操作的对象是网络文件。在任何一端读取数据时，另一端必须先写数据到网络文件中，否则就会阻塞。

java的monitor机制中,为什么阻塞队列用list等待队列用set

java阻塞队列应用于生产者消费者模式、消息传递、并行任务执行和相关并发设计的大多数常见使用上下文。

BlockingQueue在Queue接口基础上提供了额外的两种类型的操作，分别是获取元素时等待队列变为非空和添加元素时等待空间变为可用。

BlockingQueue新增操作的四种形式：

插入操作是指向队列中添加一个元素，至于元素存放的位置与具体队列的实现有关。移除操作将会移除队列的头部元素，并将这个移除的元素作为返回值反馈给调用者。检查操作是指返回队列的头元素给调用者，队列不对这个头元素进行删除处理。

抛出异常形式的操作，在队列已满的情况下，调用add方法将会抛出IllegalStateException异常。如果调用remove方法时，队列已经为空，则抛出一个NoSuchElementException异常。（实际上，remove方法还可以附带一个参数，用来删除队列中的指定元素，如果这个元素不存在，也会抛出NoSuchElementException异常）。如果调用element检查头元素，队列为空时，将会抛出NoSuchElementException异常。

特殊值操作与抛出异常不同，在出错的时候，返回一个空指针，而不会抛出异常。

阻塞形式的操作，调用put方法时，如果队列已满，则调用线程阻塞等待其它线程从队列中取出元素。调用take方法时，如果阻塞队列已经为空，则调用线程阻塞等待其它线程向队列添加新元素。

超时形式操作，在阻塞的基础上添加一个超时限制，如果等待时间超过指定值，抛出InterruptedException。

阻塞队列实现了Queue接口，而Queue接口实现了Collection接口，因此BlockingQueue也提供了remove(e)操作，即从队列中移除任意指定元素，但是这个操作往往不会按预期那样高效的执行，所以应当尽量少的使用这种操作。

阻塞队列与并发队列（例如ConcurrentLinkQueue）都是线程安全的，但使用的场合不同。

Graphic3-1给出了阻塞队列的接口方法，Graphic3-2给出了阻塞队列的实现类结构。

Graphic 3-1 BlockingQueue接口

Graphic3-2阻塞队列的实现类

3.1.1 ArrayBlockingQueue类

一个以数组为基础的有界阻塞队列，此队列按照先进先出原则对元素进行排序。队列头部元素是队列中存在时间最长的元素，队列尾部是存在时间最短的元素，新元素将会被插入到队列尾部。队列从头部开始获取元素。

ArrayBlockingQueue是“有界缓存区”模型的一种实现，一旦创建了这样的缓存区，就不能再改变缓冲区的大小。ArrayBlockingQueue的一个特点是，必须在创建的时候指定队列的大小。当缓冲区已满，则需要阻塞新增的插入操作，同理，当缓冲区已空需要阻塞新增的提取操作。

ArrayBlockingQueue是使用的是循环队列方法实现的，对ArrayBlockingQueue的相关操作的时间复杂度，可以参考循环队列进行分析。

3.1.2 LinkedBlockingQueue

一种通过链表实现的阻塞队列，支持先进先出。队列的头部是队列中保持时间最长的元素，队列的尾部是保持时间最短的元素。新元素插入队列的尾部。可选的容量设置可以有效防止队列过于扩张造成系统资源的过多消耗，如果不指定队列容量，队列默认使用Integer.MAX_VALUE。LinkedBlockingQueue的特定是，支持无限（理论上）容量。

3.1.3 PriorityBlockingQueue

PriorityBlockingQueue是一种基于优先级进行排队的无界队列。队列中的元素按照其自然顺序进行排列，或者根据提供的Comparator进行排序，这与构造队列时，提供的参数有关。

使用提取方法时，队列将返回头部，具有最高优先级（或最低优先级，这与排序规则有关）的元素。如果多个元素具有相同的优先级，则同等优先级间的元素获取次序无特殊说明。

优先级队列使用的是一种可扩展的数组结构，一般可以认为这个队列是无界的。当需要新添加一个元素时，如果此时数组已经被填满，优先队列将会自动扩充当前数组（一般认为是，先分配一个原数组一定倍数空间的数组，之后将原数组中的元素拷贝到新分配的数组中，释放原数组的空间）。

如果使用优先级队列的iterator变量队列时，不保证遍历次序按照优先级大小进行。因为优先级队列使用的是堆结构。如果需要按照次序遍历需要使用Arrays.sort(pq.toArray())。关于堆结构的相关算法，请查考数据结构相关的书籍。

在PriorityBlockingQueue的实现过程中聚合了PriorityQueue的一个实例，并且优先队列的操作完全依赖与PriorityQueue的实现。在PriorityQueue中使用了一个一维数组来存储相关的元素信息。一维数组使用最小堆算法进行元素添加。

Graphic3-3PriorityBlockingQueue的类关系

3.1.4 DelayQueue

一个无界阻塞队列，只有在延时期满时才能从中提取元素。如果没有元素到达延时期，则没有头元素。

3.2 并发集合

在多线程程序中使用的集合类，与普通程序中使用的集合类是不同的。因为有可能多个线程同时访问或修改同一集合，如果使用普通集合，很可能造成相应操作出现差错，甚至崩溃。Java提供了用于线程访问安全的集合。（前面讨论的BlockingQueue也是这里集合中的一种）。下面针对这些集合，以及集合中使用的相应算法进行探讨。在设计算法时，仅对相应算法进行简要说明，如果读者需要深入了解这些算法的原理，请参考其他的高级数据结构相关的书籍。

3.2.1 ConcurrentMap接口

ConcurrentMap接口在Map接口的基础上提供了一种线程安全的方法访问机制。ConcurrentMap接口额外提供了多线程使用的四个方法，这四个方法实际是对Map已有方法的一个组合，并对这种组合提供一种原子操作。Graphic3-4给出了ConcurrentMap相关的操作。Graphic3-5给出了ConcurrentMap的实现类关系图。

从Graphic3-5中可以看出ConcurrentNavigableMap继承自ConcurrentMap，ConcurrentNavigableMap是一种SortedMap，就是说，映射中的元素会根据键值进行排序的。在java.util类库中，有两个类实现了SortedMap接口，分别是TreeMap和ConcurrentSkipListMap。TreeMap使用的是红黑树结构。而ConcurrentSkipListMap使用作为底层实现的SkipList（翻译为跳表）数据结构。此外ConcurrentHashMap实现了ConcurrentMap接口，使用的是HashMap方法。

Graphic3-4 ConcurrentMap

Graphic3-5 实现ConcurrentMap接口。

3.2.1.1 TreeMap

尽管TreeMap不是线程安全的，但是基于其数据结构的复杂性和方便对比说明，还是在这里简单提一下。TreeMap实现了SortedMap接口。TreeMap使用的是红黑树（这是高等数据结构中的一种），在红黑树算法中，当添加或删除节点时，需要进行旋转调整树的高度。使用红黑树算法具有较好的操作特性，插入、删除、查找都能在O(log(n))时间内完成。红黑树理论和实现是很复杂的，但可以带来较高的效率，因此在许多场合也得到了广泛使用。红黑树的一个缺陷在于，可变操作很可能影响到整棵树的结构，针对修改的局部效果不好。相关算法请参考。

TreeMap不是线程安全的，如果同时有多个线程访问同一个Map，并且其中至少有一个线程从结构上修改了该映射，则必须使用外部同步。可以使用Collections.synchronizedSortedMap方法来包装该映射。（注意使用包装器包装的SortMap是线程安全的，但不是并发的，效率上很可能远远不及ConcurrentSkipListMap，因此使用包装器的方法并不十分推荐，有人认为那是一种过时的做法。包装器使用了锁机制控制对Map的并发访问，但是这种加锁的粒度可能过大，很可能影响并发度）。

3.2.1.2 ConcurrentSkipListMap

另外一种实现了SortedMap接口的映射表是ConcurrentSkipListMap。ConcurrentSkipListMap提供了一种线程安全的并发访问的排序映射表。SkipList（跳表）结构，在理论上能够在O(log(n))时间内完成查找、插入、删除操作。SkipList是一种红黑树的替代方案，由于SkipList与红黑树相比无论从理论和实现都简单许多，所以得到了很好的推广。SkipList是基于一种统计学原理实现的，有可能出现最坏情况，即查找和更新操作都是O(n)时间复杂度，但从统计学角度分析这种概率极小。Graphic3-6给出了SkipList的数据表示示例。有关skipList更多的说明可以参考： 和 这里不在累述。希望读者自行学习。

使用SkipList类型的数据结构更容易控制多线程对集合访问的处理，因为链表的局部处理性比较好，当多个线程对SkipList进行更新操作（指插入和删除）时，SkipList具有较好的局部性，每个单独的操作，对整体数据结构影响较小。而如果使用红黑树，很可能一个更新操作，将会波及整个树的结构，其局部性较差。因此使用SkipList更适合实现多个线程的并发处理。在非多线程的情况下，应当尽量使用TreeMap，因为似乎红黑树结构要比SkipList结构执行效率略优（无论是时间复杂度还是空间复杂度，作者没有做够测试，只是直觉）。此外对于并发性相对较低的并行程序可以使用Collections.synchronizedSortedMap将TreeMap进行包装，也可以提供较好的效率。对于高并发程序，应当使用ConcurrentSkipListMap，能够提供更高的并发度。

所以在多线程程序中，如果需要对Map的键值进行排序时，请尽量使用ConcurrentSkipListMap，可能得到更好的并发度。

注意，调用ConcurrentSkipListMap的size时，由于多个线程可以同时对映射表进行操作，所以映射表需要遍历整个链表才能返回元素个数，这个操作是个O(log(n))的操作。

Graphic3-6 SkipList示例

3.2.1.3 HashMap类

对Map类的另外一个实现是HashMap。HashMap使用Hash表数据结构。HashMap假定哈希函数能够将元素适当的分布在各桶之间，提供一种接近O(1)的查询和更新操作。但是如果需要对集合进行迭代，则与HashMap的容量和桶的大小有关，因此HashMap的迭代效率不会很高（尤其是你为HashMap设置了较大的容量时）。

与HashMap性能有影响的两个参数是，初始容量和加载因子。容量是哈希表中桶的数量，初始容量是哈希表在创建时的容量。加载因子是哈希表在容器容量被自动扩充之前，HashMap能够达到多满的一种程度。当hash表中的条目数超出了加载因子与当前容量的乘积时，Hash表需要进行rehash操作，此时Hash表将会扩充为以前两倍的桶数，这个扩充过程需要进行完全的拷贝工作，效率并不高，因此应当尽量避免。合理的设置Hash表的初始容量和加载因子会提高Hash表的性能。HashMap自身不是线程安全的，可以通过Collections的synchronizedMap方法对HashMap进行包装。

3.2.1.4 ConcurrentHashMap类

ConcurrentHashMap类实现了ConcurrentMap接口，并提供了与HashMap相同的规范和功能。实际上Hash表具有很好的局部可操作性，因为对Hash表的更新操作仅会影响到具体的某个桶（假设更新操作没有引发rehash），对全局并没有显著影响。因此ConcurrentHashMap可以提供很好的并发处理能力。可以通过concurrencyLevel的设置，来控制并发工作线程的数目（默认为16），合理的设置这个值，有时很重要，如果这个值设置的过高，那么很有可能浪费空间和时间，使用的值过低，又会导致线程的争用，对数量估计的过高或过低往往会带来明显的性能影响。最好在创建ConcurrentHashMap时提供一个合理的初始容量，毕竟rehash操作具有较高的代价。

3.2.2 ConcurrentSkipListSet类

实际上Set和Map从结构来说是很像的，从底层的算法原理分析，Set和Map应当属于同源的结构。所以Java也提供了TreeSet和ConcurrentSkipListSet两种SortedSet，分别适合于非多线程（或低并发多线程）和多线程程序使用。具体的算法请参考前述的Map相关介绍，这里不在累述。

3.2.3 CopyOnWriteArrayList类

CopyOnWriteArrayList是ArrayList的一个线程安全的变体，其中对于所有的可变操作都是通过对底层数组进行一次新的复制来实现的。

由于可变操作需要对底层的数据进行一次完全拷贝，因此开销一般较大，但是当遍历操作远远多于可变操作时，此方法将会更有效，这是一种被称为“快照”的模式，数组在迭代器生存期内不会发生更改，因此不会产生冲突。创建迭代器后，迭代器不会反映列表的添加、移除或者更改。不支持在迭代器上进行remove、set和add操作。CopyOnWriteArraySet与CopyOnWriteArrayList相似，只不过是Set类的一个变体。

3.2.3 Collections提供的线程安全的封装

Collections中提供了synchronizedCollection、synchronizedList、synchronizedMap、synchronizedSet、synchronizedSortedMap、synchronizedSortedMap等方法可以完成多种集合的线程安全的包装，如果在并发度不高的情况下，可以考虑使用这些包装方法，不过由于Concurrent相关的类的出现，已经不这么提倡使用这些封装了，这些方法有些人称他们为过时的线程安全机制。

3.2.4 简单总结

提供线程安全的集合简单概括分为三类，首先，对于并发性要求很高的需求可以选择以Concurrent开头的相应的集合类，这些类主要包括：ConcurrentHashMap、ConcurrentLinkedQueue、ConcurrentSkipListMap、ConcurrentSkipSet。其次对于可变操作次数远远小于遍历的情况，可以使用CopyOnWriteArrayList和CopyOnWriteArraySet类。最后，对于并发规模比较小的并行需求可以选择Collections类中的相应方法对已有集合进行封装。

此外，本章还对一些集合类的底层实现进行简单探讨，对底层实现的了解有利于对何时使用何种方式作出正确判断。希望大家能够将涉及到原理（主要有循环队列、堆、HashMap、红黑树、SkipList）进行仔细研究，这样才能更深入了解Java为什么这样设计类库，在什么情况使用，应当如何使用。

JAVA是什么意思？讲的详细一点~~~是手机软件吗？

Java名词解释

Abstract class 抽象类:抽象类是不允许实例化的类，因此一般它需要被进行扩展继承。

Abstract method 抽象方法:抽象方法即不包含任何功能代码的方法。

Access modifier 访问控制修饰符:访问控制修饰符用来修饰Java中类、以及类的方法和变量的访问控制属性。

Anonymous class 匿名类:当你需要创建和使用一个类，而又不需要给出它的名字或者再次使用的使用，就可以利用匿名类。

Anonymous inner classes 匿名内部类:匿名内部类是没有类名的局部内部类。

API 应用程序接口:提供特定功能的一组相关的类和方法的集合。

Array 数组:存储一个或者多个相同数据类型的数据结构，使用下标来访问。在Java中作为对象处理。

Automatic variables 自动变量:也称为方法局部变量method local variables，即声明在方法体中的变量。

AWT抽象窗口工具集:一个独立的API平台提供用户界面功能。

Base class 基类:即被扩展继承的类。

Blocked state 阻塞状态:当一个线程等待资源的时候即处于阻塞状态。阻塞状态不使用处理器资源

Call stack 调用堆栈:调用堆栈是一个方法列表，按调用顺序保存所有在运行期被调用的方法。

Casting 类型转换 :即一个类型到另一个类型的转换，可以是基本数据类型的转换，也可以是对象类型的转换。

char 字符:容纳单字符的一种基本数据类型。

Child class 子类:见继承类Derived class

Class 类:面向对象中的最基本、最重要的定义类型。

Class members 类成员:定义在类一级的变量，包括实例变量和静态变量。

Class methods 类方法:类方法通常是指的静态方法，即不需要实例化类就可以直接访问使用的方法。

Class variable 类变量:见静态变量Static variable

Collection 容器类:容器类可以看作是一种可以储存其他对象的对象，常见的容器类有Hashtables和Vectors。

Collection interface 容器类接口:容器类接口定义了一个对所有容器类的公共接口。

Collections framework 容器类构架:接口、实现和算法三个元素构成了容器类的架构。

Constructor 构造函数:在对象创建或者实例化时候被调用的方法。通常使用该方法来初始化数据成员和所需资源。

Containers容器:容器是一种特殊的组件，它可以容纳其他组件。

Declaration 声明:声明即是在源文件中描述类、接口、方法、包或者变量的语法。

Derived class 继承类:继承类是扩展继承某个类的类。

Encapsulation 封装性:封装性体现了面向对象程序设计的一个特性，将方法和数据组织在一起，隐藏其具体实现而对外体现出公共的接口。

Event classes 事件类:所有的事件类都定义在java.awt.event包中。

Event sources 事件源:产生事件的组件或对象称为事件源。事件源产生事件并把它传递给事件监听器event listeners。

Exception 异常:异常在Java中有两方面的意思。首先，异常是一种对象类型。其次，异常还指的是应用中发生的一种非标准流程情况，即异常状态。

Extensibility扩展性:扩展性指的是面向对象程序中，不需要重写代码和重新设计，能容易的增强源设计的功能。

Finalizer 收尾:每个类都有一个特殊的方法finalizer，它不能被直接调用，而被JVM在适当的时候调用，通常用来处理一些清理资源的工作，因此称为收尾机制。

Garbage collection 垃圾回收机制:当需要分配的内存空间不再使用的时候，JVM将调用垃圾回收机制来回收内存空间。

Guarded region 监控区域:一段用来监控错误产生的代码。

Heap堆:Java中管理内存的结构称作堆。

Identifiers 标识符:即指定类、方法、变量的名字。注意Java是大小写敏感的语言。

Import statement 引入语法:引入语法允许你可以不使用某个类的全名就可以参考这个类。

Inheritance 继承:继承是面向对象程序设计的重要特点，它是一种处理方法，通过这一方法，一个对象可以获得另一个对象的特征。

Inner classes 内部类:内部类与一般的类相似，只是它被声明在类的内部，或者甚至某个类方法体中。

Instance 实例:类实例化以后成为一个对象。

Instance variable 实例变量:实例变量定义在对象一级，它可以被类中的任何方法或者其他类的中方法访问，但是不能被静态方法访问。

Interface 接口:接口定义的是一组方法或者一个公共接口，它必须通过类来实现。

Java source file Java源文件:Java源程序包含的是Java程序语言计算机指令。

Java Virtual Machine (JVM) Java虚拟机:解释和执行Java字节码的程序，其中Java字节码由Java编译器生成。

javac Java编译器:Javac是Java编译程序的名称。

JVM Java虚拟机:见Java虚拟机

Keywords 关键字:即Java中的保留字，不能用作其他的标识符。

Layout managers 布局管理器:布局管理器是一些用来负责处理容器中的组件布局排列的类。

Local inner classes 局部内部类:在方法体中，或者甚至更小的语句块中定义的内部类。

Local variable 局部变量:在方法体中声明的变量

Member inner classes 成员内部类:定义在封装类中的没有指定static修饰符的内部类。

Members 成员:类中的元素，包括方法和变量。

Method 方法:完成特定功能的一段源代码，可以传递参数和返回结果，定义在类中。

Method local variables 方法局部变量:见自动变量Automatic variables

Modifier 修饰符:用来修饰类、方法或者变量行为的关键字。

Native methods 本地方法:本地方法是指使用依赖平台的语言编写的方法，它用来完成Java无法处理的某些依赖于平台的功能。

Object 对象:一旦类实例化之后就成为对象。

Overloaded methods 名称重载方法:方法的名称重载是指同一个类中具有多个方法，使用相同的名称而只是其参数列表不同。

Overridden methods 覆盖重载方法:方法的覆盖重载是指父类和子类使用的方法采用同样的名称、参数列表和返回类型。

Package 包:包即是将一些类聚集在一起的一个实体。

Parent class 父类:被其他类继承的类。也见基类。

Private members 私有成员:私有成员只能在当前类被访问，其他任何类都不可以访问之。

Public members 公共成员:公共成员可以被任何类访问，而不管该类属于那个包。

Runtime exceptions 运行时间异常:运行时间异常是一种不能被你自己的程序处理的异常。通常用来指示程序BUG。

Source file 源文件:源文件是包含你的Java代码的一个纯文本文件。

Stack trace 堆栈轨迹:如果你需要打印出某个时间的调用堆栈状态，你将产生一个堆栈轨迹。

Static inner classes 静态内部类:静态内部类是内部类最简单的形式，它于一般的类很相似，除了被定义在了某个类的内部。

Static methods 静态方法:静态方法声明一个方法属于整个类，即它可以不需要实例化一个类就可以通过类直接访问之。

Static variable 静态变量:也可以称作类变量。它类似于静态方法，也是可以不需要实例化类就可以通过类直接访问。

Superclass 超类:被一个或多个类继承的类。

Synchronized methods 同步方法:同步方法是指明某个方法在某个时刻只能由一个线程访问。

Thread 线程:线程是一个程序内部的顺序控制流。

Time-slicing 时间片:调度安排线程执行的一种方案。

Variable access 变量访问控制:变量访问控制是指某个类读或者改变一个其他类中的变量的能力。

Visibility 可见性: 可见性体现了方法和实例变量对其他类和包的访问控制。

容器：充当中间件的角色

WEB容器：给处于其中的应用程序组件（JSP，SERVLET）提供一个环境，使JSP,SERVLET直接更容器中的环境变量接口交互，不必关注其它系统问题。主要有WEB服务器来实现。例如：TOMCAT,WEBLOGIC,WEBSPHERE等。该容器提供的接口严格遵守J2EE规范中的WEB APPLICATION 标准。我们把遵守以上标准的WEB服务器就叫做J2EE中的WEB容器。

EJB容器：Enterprise java bean 容器。更具有行业领域特色。他提供给运行在其中的组件EJB各种管理功能。只要满足J2EE规范的EJB放入该容器，马上就会被容器进行高效率的管理。并且可以通过现成的接口来获得系统级别的服务。例如邮件服务、事务管理。

WEB容器和EJB容器在原理上是大体相同的，更多的区别是被隔离的外界环境。WEB容器更多的是跟基于HTTP的请求打交道。而EJB容器不是。它是更多的跟数据库、其它服务打交道。但他们都是把与外界的交互实现从而减轻应用程序的负担。例如SERVLET不用关心HTTP的细节，直接引用环境变量session,request,response就行、EJB不用关心数据库连接速度、各种事务控制，直接由容器来完成。

RMI/IIOP:远程方法调用/internet对象请求中介协议，他们主要用于通过远程调用服务。例如，远程有一台计算机上运行一个程序，它提供股票分析服务，我们可以在本地计算机上实现对其直接调用。当然这是要通过一定的规范才能在异构的系统之间进行通信。RMI是JAVA特有的。

JNDI:JAVA命名目录服务。主要提供的功能是：提供一个目录系统，让其它各地的应用程序在其上面留下自己的索引，从而满足快速查找和定位分布式应用程序的功能。

JMS:JAVA消息服务。主要实现各个应用程序之间的通讯。包括点对点和广播。

JAVAMAIL:JAVA邮件服务。提供邮件的存储、传输功能。他是JAVA编程中实现邮件功能的核心。相当MS中的EXCHANGE开发包。

JTA：JAVA事务服务。提供各种分布式事务服务。应用程序只需调用其提供的接口即可。

JAF:JAVA安全认证框架。提供一些安全控制方面的框架。让开发者通过各种部署和自定义实现自己的个性安全控制策略。

EAI:企业应用集成。是一种概念，从而牵涉到好多技术。J2EE技术是一种很好的集成实现。

Java 多线程 资源冲突

这是javaeye上非常经典的关于线程的帖子，写的非常通俗易懂的，适合任何读计算机的同学.

线程同步

我们可以在计算机上运行各种计算机软件程序。每一个运行的程序可能包括多个独立运行的线程（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阻塞原理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java中阻塞和非阻塞、java阻塞原理的信息别忘了在本站进行查找喔。