【黑马程序员】多线程总结

——Java培训、Android培训、iOS培训、.Net培训、期待与您交流！ ——-

这是我学习多线程两天后对于不明白的地方上网查阅大量资料后,针对一些难点做的一些总结.

线程的状态：

新建状态：新创建线程对象，但是该线程尚未运行。

就绪状态：线程对象创建后，其他线程调用了该对象的start（）方法。此线程开始运行，等待获取CPU的使用权。

运行状态：就绪状态的线程获取了CPU使用权，开始执行他的run方法。

阻塞状态：阻塞状态是线程因为某种原因失去CPU使用权。等待其他操作让线程进入就绪状态.

阻塞的情况分三种：

1. 等待阻塞：运行的线程执行wait（）方法，JVM会把该线程放入等待池中。

2. 同步阻塞：运行的线程在获取对象的同步锁时，锁已被别的线程占用， 只能执行未被同步的代码块,并等待获取到锁。

3. 其他阻塞：运行的线程执行sleep（）或join（）方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep（）状态超时、join（）等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。

死亡状态：线程运行完毕变成垃圾,等待回收. 进入死亡状态的两种方式:

1. run方法执行完毕;
2. 没有捕获到的异常终止了run方法的执行，导致线程猝死~

多线程实现方式

1. 继承Thread类
2. 实现Runnable接口
3. 使用ExecutorService、Callable、Future实现有返回值的多线程。

前两种方式最常用,但是线程执行完后没有返回值，只有第三种是带返回值的。

几个方法的区别

1. sleep方法与wait方法的区别：
   sleep方法是静态的，wait方法是非静态的。
   sleep方法在时间到后会自己“醒来”,线程进入就绪状态，但wait不能，必须由其它线程通过notify方法唤醒。
   sleep方法通常用在不需要等待资源情况下的阻塞，而像等待线程、数据库连接的情况一般用wait。
   sleep()方法不会释放锁,wait()会

2. sleep/wait与yeld方法的区别：
   调用sleep或wait方法后，线程即进入阻塞状态，而调用yeld方法后，进入就绪状态。
   sleep() 方法声明抛出InterruptedException，而 yield() 方法没有声明任何异常
   sleep()方法会给其他线程运行的机会,而不管其他线程的优先级,因此会给较低优先级的线程运行的机会;
   yeild()方法只会给优先级相同的或者比自己高的线程运行的机会.

3. wait与join方法的区别：
   wait方法体现了线程之间的互斥关系，而join方法体现了线程之间的同步关系。
   wait方法必须由其它线程来唤醒，而join方法不需要，只要被等待线程执行完毕，当前线程自动变为就绪。
   join方法的一个用途就是让子线程在完成执行之前，主线程一直等待直到所有子线程执行完毕。

4. run方法和start方法的区别
   run方法包含那些被线程执行的代码,不在run方法里的不执行,run方法并不启动线程,需要start方法启动
   start方法会启动线程,然后自动调用run.若想创建多个线程,就创建多个对象分别调用start方法

多线程容易出现问题的几个地方

在构造函数中启动线程

示例如下:

public class A{
    private int x;
    private int y;
    private Thread thread;
    public A(){
        this.x=1;
        this.y=2;
        this.thread=new MyThread();
        this.thread.start();
    }   
}

如果有个类B继承了类A，依据java类初始化的顺序，A的构造函数一定会在B的构造函数调用前被调用，那么thread线程也将在B被完全初始化之前启动，当thread运行时使用到了类A中的某些变量，那么就可能使用的不是你预期中的值，因为在B的构造函数中你可能赋给这些变量新的值。也就是说此时将有两个线程在使用这些变量，而这些变量却没有同步。

解决办法：将A类设置为final，不可继承；或者提供单独的start方法用来启动线程，而不是放在构造函数中。

不完全的同步

我们都知道对一个变量同步的有效方式是用synchronized保护起来，当你将某个变量在A方法中同步，那么在变量出现的其他地方，你也需要同步，除非你允许弱可见性甚至产生错误值。类似这样的代码：

class A{
    int x;
    public int getX(){
        return x;
    }
    public synchronized void setX(int x){
        this.x=x;
    }
}

x的setter方法有同步，然而getter方法却没有，那么就无法保证其他线程通过getX得到的x是最新的值。事实上，如果这样写,这里的setX的同步就变得无意义

在使用某个对象当锁时，改变了对象的引用，导致同步失效。

这也是很常见的错误，类似下面的代码：

synchronized(array[0]){
   ......
   array[0]=new A();
   ......
}

同步块使用array[0]作为锁，然而在同步块中却改变了array[0]指向的引用。

分析下这个场景，第一个线程获取了array[0]的锁，第二个线程因为无法获取array[0]而等待，在改变了array[0]的引用后，第三个线程获取了新的array[0]的锁，第一和第三两个线程持有的锁是不一样的，同步互斥的目的就完全没有达到了。

这样代码的修改，通常是将锁声明为final变量或者引入业务无关的锁对象，保证在同步块内不会被修改引用。

在调用wait()前需要做条件判断时用if而不是while

很多代码做到了同步，却没有在循环中调用wait，而是使用if甚至没有条件判断：

synchronized(lock){
    if(x.isEmpty())
        lock.wait();   
}

对条件的判断使用if，这会造成什么问题呢？
在判断条件之前可能调用notify或者notifyAll，那么条件已经满足，不会等待，这没什么问题。
在条件没有满足，调用了wait（）方法，释放lock锁并进入等待休眠状态。如果线程是在正常情况下，也就是条件被改变之后被唤醒，那么没有任何问题，条件满足继续执行下面的逻辑操作。
问题在于线程可能被意外甚至恶意唤醒，由于没有再次进行条件判断，在条件没有被满足的情况下，线程执行了后续的操作。
意外唤醒的情况，可能是调用了notifyAll，可能是有人恶意唤醒，也可能是很少情况下的自动苏醒。

因此为了防止这种条件没有满足就执行后续操作的情况，需要在被唤醒后再次判断条件，如果条件不满足，继续进入等待状态，条件满足，才进行后续操作。

synchronized(lock){
    while(x.isEmpty()){
        lock.wait(); 
    }  
}

没有进行条件判断就调用wait的情况更严重，因为在等待之前可能notify已经被调用，那么在调用了wait之后进入等待休眠状态后就无法保证线程苏醒过来。

同步的范围过小或者过大

同步的范围过小，可能完全没有达到同步的目的；同步的范围过大，可能会影响性能。同步范围过小的一个常见例子是误认为两个同步的方法一起调用也是将同步的

   Map map=Collections.synchronizedMap(new HashMap());
   if(!map.containsKey('a')){
        map.put('a', value);
   }

这是一个很典型的错误，map是线程安全的，containskey和put方法也是线程安全的，然而两个线程安全的方法被组合调用就不一定是线程安全的了。

因为在containsKey和put之间，可能有其他线程抢先put进了a，那么就可能覆盖了其他线程设置的值，导致值的丢失。

解决这一问题的方法就是扩大同步范围，因为对象锁是可重入的，因此在线程安全方法之上再同步相同的锁对象不会有问题。

    Map map = Collections.synchronizedMap(new HashMap());
    synchronized (map) {
        if (!map.containsKey("a")) {
            map.put("a", value);
        }
    }

注意，加大锁的范围，要保证使用的是同一个锁，不然很可能造成死锁。
Collections.synchronizedMap（new HashMap（））使用的锁是map本身，因此没有问题。

同步范围过大的例子也很多，比如在同步块中new大对象，或者调用费时的IO操作（操作数据库，webservice等）。在不得不调用费时操作的时候，一定要指定超时时间，防止锁被独占不释放。
同步范围过大的情况下，要在保证线程安全的前提下，将不必要同步的操作从同步块中移出。

线程不安全!=不安全

在使用过程中时常有一个不正确的观点：我的程序是多线程的，必须通过同步等方式要保证线程安全。

注意:线程不安全并不是多线程环境下就不能使用。我们要记住,判断一个程序是否有线程安全问题的依据:
是否有多线程环境?
是否有共享数据?
是否有多条语句操作共享数据?