六：wait与notify

1.wait与notify方法都是定义在Object类中，而且是final的，因此会被所有的Java类所继承并且无法重写。这两个方法要求在调用时线程应该已经获得了对象的锁，因此对这两个方法的调用需要放在synchronized方法或块当中。当线程执行了wait方法时，它会释放掉对象的锁。

2. 另一个会导致线程暂停的方法就是Thread类的sleep方法，它会导致线程睡眠指定的毫秒数，但线程在睡眠的过程中是不会释放掉对象的锁的。

3.notify():唤醒在此对象监视器上等待的单个线程。如果所有线程都在此对象上等待，则会选择唤醒其中一个线程。选择是任意性的，并在对实现做出决定时发生。线程通过调用其中一个 wait 方法，在对象的监视器上等待。

直到当前线程放弃此对象上的锁定，才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争；例如，唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。

此方法只应由作为此对象监视器的所有者的线程来调用。通过以下三种方法之一，线程可以成为此对象监视器的所有者：

o 通过执行此对象的同步实例方法。

o 通过执行在此对象上进行同步的 synchronized 语句的正文。

o 对于 Class 类型的对象，可以通过执行该类的同步静态方法。

一次只能有一个线程拥有对象的监视器。

关于成员变量与局部变量：如果一个变量是成员变量，那么多个线程对同一个对象的成员变量进行操作时，他们对该成员变量是彼此影响的（也就是说一个线程对成员变量的改变会影响到另一个线程）。  如果一个变量是局部变量，那么每个线程都会有一个该局部变量的拷贝，一个线程对该局部变量的改变不会影响到其他的线程。

七：死锁的问题：

定义：线程1锁住了对象A的监视器，等待对象B的监视器，线程2锁住了对象B的监视器，等待对象A的监视器，就造成了死锁。

     导致死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的作用是，确保在某个时刻只有一个线程被允许执行特定的代码块，因此，被允许执行的线程首先必须拥有对变量或对象的排他性访问权。当线程访问对象时，线程会给对象加锁

Java中每个对象都有一把锁与之对应。但Java不提供单独的lock和unlock操作。下面笔者分析死锁的两个过程“上锁”和“锁死” 。

(1) 上锁
     许多线程在执行中必须考虑与其他线程之间共享数据或协调执行状态，就需要同步机制。因此大多数应用程序要求线程互相通信来同步它们的动作，在 Java 程序中最简单实现同步的方法就是上锁。在 Java 编程中，所有的对象都有锁。线程可以使用 synchronized 关键字来获得锁。在任一时刻对于给定的类的实例，方法或同步的代码块只能被一个线程执行。这是因为代码在执行之前要求获得对象的锁。

    为了防止同时访问共享资源，线程在使用资源的前后可以给该资源上锁和开锁。给共享变量上锁就使得 Java 线程能够快速方便地通信和同步。某个线程若给一个对象上了锁，就可以知道没有其他线程能够访问该对象。即使在抢占式模型中，其他线程也不能够访问此对象，直到上锁的线程被唤醒、完成工作并开锁。那些试图访问一个上锁对象的线程通常会进入睡眠状态，直到上锁的线程开锁。一旦锁被打开，这些睡眠进程就会被唤醒并移到准备就绪队列中。

(2)锁死
     如果程序中有几个竞争资源的并发线程,那么保证均衡是很重要的。系统均衡是指每个线程在执行过程中都能充分访问有限的资源，系统中没有饿死和死锁的线程。当多个并发的线程分别试图同时占有两个锁时，会出现加锁冲突的情形。如果一个线程占有了另一个线程必需的锁，互相等待时被阻塞就有可能出现死锁。

    在编写多线程代码时，笔者认为死锁是最难处理的问题之一。因为死锁可能在最意想不到的地方发生，所以查找和修正它既费时又费力。例如，常见的例子如下面这段程序。print?

1 public int sumArrays(int[] a1, int[] a2){  

2   int value = 0;  

3   int size = a1.length;  

4   if (size == a2.length) {  

5      synchronized(a1) { //1        

6        synchronized(a2) { //2         

7          for (int i=0; i<size; i++)  

8             value += a1 + a2;  

9        }   

10      }   

11   } return value;  

12 }   

这段代码在求和操作中访问两个数组对象之前锁定了这两个数组对象。它形式简短，编写也适合所要执行的任务；但不幸的是，它有一个潜在的问题。这个问题就是它埋下了死锁的种子。

ThreadLocal类（这个类本人没用过，占时不太懂）

首先，ThreadLocal 不是用来解决共享对象的多线程访问问题的，一般情况下，通过ThreadLocal.set() 到线程中的对象是该线程自己使用的对象，其他线程是不需要访问的，也访问不到的。各个线程中访问的是不同的对象。

另外，说ThreadLocal使得各线程能够保持各自独立的一个对象，并不是通过ThreadLocal.set()来实现的，而是通过每个线程中的new 对象 的操作来创建的对象，每个线程创建一个，不是什么对象的拷贝或副本。通过ThreadLocal.set()将这个新创建的对象的引用保存到各线程的自己的一个map中，每个线程都有这样一个map，执行ThreadLocal.get()时，各线程从自己的map中取出放进去的对象，因此取出来的是各自自己线程中的对象，ThreadLocal实例是作为map的key来使用的。

如果ThreadLocal.set()进去的东西本来就是多个线程共享的同一个对象，那么多个线程的ThreadLocal.get()取得的还是这个共享对象本身，还是有并发访问问题

六：wait与notify

1.wait与notify方法都是定义在Object类中，而且是final的，因此会被所有的Java类所继承并且无法重写。这两个方法要求在调用时线程应该已经获得了对象的锁，因此对这两个方法的调用需要放在synchronized方法或块当中。当线程执行了wait方法时，它会释放掉对象的锁。

2. 另一个会导致线程暂停的方法就是Thread类的sleep方法，它会导致线程睡眠指定的毫秒数，但线程在睡眠的过程中是不会释放掉对象的锁的。

3.notify():唤醒在此对象监视器上等待的单个线程。如果所有线程都在此对象上等待，则会选择唤醒其中一个线程。选择是任意性的，并在对实现做出决定时发生。线程通过调用其中一个 wait 方法，在对象的监视器上等待。

直到当前线程放弃此对象上的锁定，才能继续执行被唤醒的线程。被唤醒的线程将以常规方式与在该对象上主动同步的其他所有线程进行竞争；例如，唤醒的线程在作为锁定此对象的下一个线程方面没有可靠的特权或劣势。

此方法只应由作为此对象监视器的所有者的线程来调用。通过以下三种方法之一，线程可以成为此对象监视器的所有者：

o 通过执行此对象的同步实例方法。

o 通过执行在此对象上进行同步的 synchronized 语句的正文。

o 对于 Class 类型的对象，可以通过执行该类的同步静态方法。

一次只能有一个线程拥有对象的监视器。

关于成员变量与局部变量：如果一个变量是成员变量，那么多个线程对同一个对象的成员变量进行操作时，他们对该成员变量是彼此影响的（也就是说一个线程对成员变量的改变会影响到另一个线程）。  如果一个变量是局部变量，那么每个线程都会有一个该局部变量的拷贝，一个线程对该局部变量的改变不会影响到其他的线程。

七：死锁的问题：

定义：线程1锁住了对象A的监视器，等待对象B的监视器，线程2锁住了对象B的监视器，等待对象A的监视器，就造成了死锁。

     导致死锁的根源在于不适当地运用“synchronized”关键词来管理线程对特定对象的访问。“synchronized”关键词的作用是，确保在某个时刻只有一个线程被允许执行特定的代码块，因此，被允许执行的线程首先必须拥有对变量或对象的排他性访问权。当线程访问对象时，线程会给对象加锁

Java中每个对象都有一把锁与之对应。但Java不提供单独的lock和unlock操作。下面笔者分析死锁的两个过程“上锁”和“锁死” 。

(1) 上锁
     许多线程在执行中必须考虑与其他线程之间共享数据或协调执行状态，就需要同步机制。因此大多数应用程序要求线程互相通信来同步它们的动作，在 Java 程序中最简单实现同步的方法就是上锁。在 Java 编程中，所有的对象都有锁。线程可以使用 synchronized 关键字来获得锁。在任一时刻对于给定的类的实例，方法或同步的代码块只能被一个线程执行。这是因为代码在执行之前要求获得对象的锁。

    为了防止同时访问共享资源，线程在使用资源的前后可以给该资源上锁和开锁。给共享变量上锁就使得 Java 线程能够快速方便地通信和同步。某个线程若给一个对象上了锁，就可以知道没有其他线程能够访问该对象。即使在抢占式模型中，其他线程也不能够访问此对象，直到上锁的线程被唤醒、完成工作并开锁。那些试图访问一个上锁对象的线程通常会进入睡眠状态，直到上锁的线程开锁。一旦锁被打开，这些睡眠进程就会被唤醒并移到准备就绪队列中。

(2)锁死
     如果程序中有几个竞争资源的并发线程,那么保证均衡是很重要的。系统均衡是指每个线程在执行过程中都能充分访问有限的资源，系统中没有饿死和死锁的线程。当多个并发的线程分别试图同时占有两个锁时，会出现加锁冲突的情形。如果一个线程占有了另一个线程必需的锁，互相等待时被阻塞就有可能出现死锁。

    在编写多线程代码时，笔者认为死锁是最难处理的问题之一。因为死锁可能在最意想不到的地方发生，所以查找和修正它既费时又费力。例如，常见的例子如下面这段程序。print?

1 public int sumArrays(int[] a1, int[] a2){  

2   int value = 0;  

3   int size = a1.length;  

4   if (size == a2.length) {  

5      synchronized(a1) { //1        

6        synchronized(a2) { //2         

7          for (int i=0; i<size; i++)  

8             value += a1 + a2;  

9        }   

10      }   

11   } return value;  

12 }   

这段代码在求和操作中访问两个数组对象之前锁定了这两个数组对象。它形式简短，编写也适合所要执行的任务；但不幸的是，它有一个潜在的问题。这个问题就是它埋下了死锁的种子。

ThreadLocal类（这个类本人没用过，占时不太懂）

首先，ThreadLocal 不是用来解决共享对象的多线程访问问题的，一般情况下，通过ThreadLocal.set() 到线程中的对象是该线程自己使用的对象，其他线程是不需要访问的，也访问不到的。各个线程中访问的是不同的对象。

另外，说ThreadLocal使得各线程能够保持各自独立的一个对象，并不是通过ThreadLocal.set()来实现的，而是通过每个线程中的new 对象 的操作来创建的对象，每个线程创建一个，不是什么对象的拷贝或副本。通过ThreadLocal.set()将这个新创建的对象的引用保存到各线程的自己的一个map中，每个线程都有这样一个map，执行ThreadLocal.get()时，各线程从自己的map中取出放进去的对象，因此取出来的是各自自己线程中的对象，ThreadLocal实例是作为map的key来使用的。

如果ThreadLocal.set()进去的东西本来就是多个线程共享的同一个对象，那么多个线程的ThreadLocal.get()取得的还是这个共享对象本身，还是有并发访问问题