线程基础

Thread和Runnable： public  class Thread implements Runnable

     在java中可有两种方式实现多线程， 一种是继承Thread类，一种是实现Runnable接口 ；Thread类是在java.lang包中定义的。一个类只要继承了Thread类同时覆写了本类中的run()方法就可以实现多线程操作了，但是一个类只能继承一个父类，这是此方法的局限。

     在程序开发中只要是多线程肯定永远以实现Runnable接口为主，因为实现Runnable接口相比继承Thread类有如下好处： 避免单点继承的局限，一个类可以继承多个接口。 适合于资源的共享。

线程变化的状态转换图例如以下：

　　1、新建状态(New)：新创建了一个线程对象。

　　2、就绪状态(Runnable)：线程对象创建后，其它线程调用了该对象的start()方法。

该状态的线程位于可执行线程池中，变得可执行，等待获取CPU的使用权。

　　3、执行状态(Running)：就绪状态的线程获取了CPU。执行程序代码。

　　4、堵塞状态(Blocked)：堵塞状态是线程由于某种原因放弃CPU使用权。临时停止执行。直到线程进入就绪状态，才有机会转到执行状态。

堵塞的情况分三种：

　　(一)、等待堵塞：执行的线程执行wait()方法，JVM会把该线程放入等待池中。

　　(二)、同步堵塞：执行的线程在获取对象的同步锁时，若该同步锁被别的线程占用。则JVM会把该线程放入锁池中。

　　(三)、其它堵塞：执行的线程执行sleep()或join()方法，或者发出了I/O请求时。JVM会把该线程置为堵塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完成时。线程又一次转入就绪状态。

　　5、死亡状态(Dead)：线程运行完了或者因异常退出了run()方法，该线程结束生命周期。

   

1、线程的实现有两种方式，一是继承Thread类，二是实现Runnable接口，但无论如何，当我们new了这个对象后。线程就进入了初始状态；

2、当该对象调用了start()方法，就进入可执行状态；

3、进入可执行状态后，当该对象被操作系统选中。获得CPU时间片就会进入执行状态；

4、进入执行状态后情况就比較复杂了

    4.1、run()方法或main()方法结束后，线程就进入终止状态；

    4.2、当线程调用了自身的sleep()方法或其它线程的join()方法，就会进入堵塞状态（该状态既停止当前线程，但并不释放所占有的资源）。当sleep()结束或join()结束后。该线程进入可执行状态，继续等待OS分配时间片；

    4.3、线程调用了yield()方法，意思是放弃当前获得的CPU时间片，回到可执行状态，这时与其它进程处于同等竞争状态，OS有可能会接着又让这个进程进入执行状态。

   4.4、当线程刚进入可执行状态（注意，还没执行），发现将要调用的资源被synchroniza（同步），获取不到锁标记。将会马上进入锁池状态，等待获取锁标记（这时的锁池里或许已经有了其它线程在等待获取锁标记，这时它们处于队列状态，既先到先得），一旦线程获得锁标记后，就转入可执行状态。等待OS分配CPU时间片。

   4.5、当线程调用wait()方法后会进入等待队列（进入这个状态会释放所占有的全部资源，与堵塞状态不同）。进入这个状态后。是不能自己主动唤醒的，必须依靠其它线程调用notify()或notifyAll()方法才会被唤醒（因为notify()仅仅是唤醒一个线程，但我们由不能确定详细唤醒的是哪一个线程。或许我们须要唤醒的线程不可以被唤醒，因此在实际使用时，一般都用notifyAll()方法，唤醒有所线程），线程被唤醒后会进入锁池。等待获取锁标记。

为什么使用线程池？

    诸如 Web 服务器、数据库服务器、文件服务器或邮件服务器之类的许多服务器应用程序都面向处理来自某些远程来源的大量短小的任务。请求以某种方式到达服务器，这种方式可能是通过网络协议（例如 HTTP、FTP 或 POP）、通过 JMS 队列或者可能通过轮询数据库。不管请求如何到达，服务器应用程序中经常出现的情况是：单个任务处理的时间很短而请求的数目却是巨大的。

    构建服务器应用程序的一个简单模型是：每当一个请求到达就创建一个新线程，然后在新线程中为请求服务。实际上对于原型开发这种方法工作得很好，但如果试图部署以这种方式运行的服务器应用程序，那么这种方法的严重不足就很明显。每个请求对应一个线程（thread-per-request）方法的不足之一是：为每个请求创建一个新线程的开销很大；为每个请求创建新线程的服务器在创建和销毁线程上花费的时间和消耗的系统资源要比花在处理实际的用户请求的时间和资源更多。

    除了创建和销毁线程的开销之外，活动的线程也消耗系统资源。在一个 JVM 里创建太多的线程可能会导致系统由于过度消耗内存而用完内存或“切换过度”。为了防止资源不足，服务器应用程序需要一些办法来限制任何给定时刻处理的请求数目。

    线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一直等待，直到获得一个线程来处理为止，从而可以防止资源不足。

常用的几种线程池：

   1、  newCachedThreadPool

        创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。

    这种类型的线程池特点是：

        工作线程的创建数量几乎没有限制(其实也有限制的,数目为Interger. MAX_VALUE), 这样可灵活的往线程池中添加线程。 如果长时间没有往线程池中提交任务，即如果工作线程空闲了指定的时间(默认为1分钟)，则该工作线程将自动终止。终止后，如果你又提交了新的任务，则线程池重新创建一个工作线程。

    2、  newFixedThreadPool

        创建一个指定工作线程数量的线程池。每当提交一个任务就创建一个工作线程，如果工作线程数量达到线程池初始的最大数，则将提交的任务存入到池队列中。

        FixedThreadPool是一个典型且优秀的线程池，它具有线程池提高程序效率和节省创建线程时所耗的开销的优点。但是，在线程池空闲时，即线程池中没有可运行任务时，它不会释放工作线程，还会占用一定的系统资源。

    3、 newSingleThreadExecutor

        创建一个单线程化的Executor，即只创建唯一的工作者线程来执行任务，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。如果这个线程异常结束，会有另一个取代它，保证顺序执行。单工作线程最大的特点是可保证顺序地执行各个任务，并且在任意给定的时间不会有多个线程是活动的。

        在使用CachedThreadPool时，一定要注意控制任务的数量，否则，由于大量线程同时运行，很有会造成系统瘫痪。

    4、 newScheduleThreadPool

        创建一个定长的线程池，而且支持定时的以及周期性的任务执行，支持定时及周期性任务执行。

1、ReentrantLock 拥有Synchronized相同的并发性和内存语义，此外还多了锁投票，定时锁等候和中断锁等候

     线程A和B都要获取对象O的锁定，假设A获取了对象O锁，B将等待A释放对O的锁定，

     如果使用 synchronized ，如果A不释放，B将一直等下去，不能被中断

     如果 使用ReentrantLock，如果A不释放，可以使B在等待了足够长的时间以后，中断等待，而干别的事情

 

    ReentrantLock获取锁定与三种方式：

    a)  lock(), 如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁

    b) tryLock(), 如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；

    c)tryLock(long timeout,TimeUnit unit)，   如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；

    d) lockInterruptibly:如果获取了锁定立即返回，如果没有获取锁定，当前线程处于休眠状态，直到或者锁定，或者当前线程被别的线程中断。

    synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定，但是使用Lock则不行，lock是通过代码实现的，要保证锁定一定会被释放，就必须将unLock()放到finally{}中。

      在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态；

Atomic: 

    和上面的类似，不激烈情况下，性能比synchronized略逊，而激烈的时候，也能维持常态。激烈的时候，Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点，就是只能同步一个值，一段代码中只能出现一个Atomic的变量，多于一个同步无效。因为他不能在多个Atomic之间同步。 

1.Synchronized

    Synchronized进过编译，会在同步块的前后分别形 成monitorenter和monitorexit这个两个字节码指令 。在执行monitorenter指令时，首先要尝试获取对象锁。如果这个对象没被锁定，或者当前线程已经拥有了那个对象锁，把锁的计算器加1，相应的，在执行monitorexit指令时会将锁计算器就减1，当计算器为0时，锁就被释放了。如果获取对象锁失败，那当前线程就要阻塞，直到对象锁被另一个线程释放为止。

2.ReentrantLock

   由于ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比Synchronized，ReentrantLock类提供了一些高级功能，主要有以下3项：

        1.等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。

        2.公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。

        3.锁绑定多个条件，一个ReentrantLock对象可以同时绑定多个对象。

死锁：

    任何多线程应用程序都有死锁风险。当一组进程或线程中的每一个都在等待一个只有该组中另一个进程才能引起的事件时，我们就说这组进程或线程 死锁了。死锁的最简单情形是：线程 A 持有对象 X 的独占锁，并且在等待对象 Y 的锁，而线程 B 持有对象 Y 的独占锁，却在等待对象 X 的锁。除非有某种方法来打破对锁的等待（Java 锁定不支持这种方法），否则死锁的线程将永远等下去。

虽然任何多线程程序中都有死锁的风险，但线程池却引入了另一种死锁可能，在那种情况下，所有池线程都在执行已阻塞的等待队列中另一任务的执行结果的任务，但这一任务却因为没有未被占用的线程而不能运行。当线程池被用来实现涉及许多交互对象的模拟，被模拟的对象可以相互发送查询，这些查询接下来作为排队的任务执行，查询对象又同步等待着响应时，会发生这种情况。