一、多线程基础知识
①、进程和线程的区别
线程：线程是进程当中独立运行的子任务。
②、java.exe、javaw.exe和javaws.exe
javaw.exe主要用于启动基于GUI的应用程序。
java.exe执行应用日志再在控制台显示输出与错误信息。
javaws.exe是用来启动通过web来描述的项目，我们需要一个jnlp文件，来描述javaws.exe需要运行的程序
③、Thread的start()方法和run()方法、sleep()方法
用start()方法启动线程以后，只是通知“线程规划器”此线程已经准备就绪，等待调用线程对象的run()方法。这个线程让系统安排一个时间来调用Thread的run()方法，具有异步执行的效果。而run()不是异步的，而是同步执行的。Thread.sleep()会让当前线程阻塞，如果在主线程中通过start()调用时，调用的线程是main，如果直接用run()调用的话则直接是当前线程调用Thread-0
④currentThread()方法
Thread.curredntThread()返回代码段在被那个线程调用的信息。
⑤、isAlive()
Thread.currentThread().isAlive() 当前线程是否处于活跃状态。
在自定义线程类时，如果线程类是继承java.lang.Thread的话，那么线程类就可以使用this关键字去调用继承自父类Thread的方法，this就是当前的对象。
Thread.currentThread()可以获取当前线程的引用，一般都是在没有线程对象又需要获得线程信息时通过Thread.currentThread()获取当前代码段所在线程的引用。
https://blog.csdn.net/yezis/article/details/57513130
⑥、sleep()
在指定的毫秒内让当前“正在执行的线程”休眠（暂停执行），这个“正在执行的线程”是指this.currentThread()返回的线程。
⑦、getId()
Thread.currentThread().getId();获得当前线程的id
⑧、停止线程的方法
(1)当run方法完成后线程终止
(2)使用stop方法强行终止线程，不推荐使用，和suspend及resume一样被废弃调了
(3)使用interrupt方法中断（线程不会真的停止）
interrupt()仅仅是在当前线程中打了一个停止标记，并不是真的停止线程，判断线程是否停止的方法
1）this.interrupted():测试当前线程是否已经是中断状态，并将标志状态清除为false。 是静态方法，可以通过Thread.interrupted()来进行判断
2）this.isInterrupted()：测试线程Thread对象是否已经是中断状态，但不清楚状态标志。是非静态方法，通过对象进行判断。
⑨、如何真正停止线程,抛出异常
/**
* @author 赵洪坤
* @日期2018年6月6日
*/
public class ExtendThread extends Thread {
@Override
public void run() {
super.run();
try {
for (int i = 0; i < 50000; i++) {
if (this.interrupted()) {
System.out.println("已经是停止状态了！我要退出");
throw new InterruptedException();
}
System.out.println("i=" + (i + 1));
}
System.out.println("for循环又继续了");
} catch (InterruptedException e) {
System.out.println("进入interrupt异常");
e.printStackTrace();
}
}
}
/**
* @author 赵洪坤
* @日期2018年6月6日
*/
public class Main {
/**
* @author 赵洪坤
* @日期2018年6月6日
* @param args
* @throws InterruptedException
*/
public static void main(String[] args) {
try {
ExtendThread extendThread = new ExtendThread();
extendThread.start();
Thread.sleep(200);
extendThread.interrupt();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
⑩、stop暴力停止线程
（1）stop()停止线程相当于电脑拔掉电源，可能使一些清理邢的工作得不到完成。
（2）对锁的对象进行了“解锁”，导致数据得不到同步处理，出现数据不一致
⑪、suspend的暂停线程，resume重新开始线程
（1）缺点-使用不当，容易造成公共的同步对象的独占
（2）缺点-不同步
⑫、yield方法
放弃当前cpu的资源，将它让给其它的任务去占用cpu的执行时间。但放弃的时间不确定，有可能刚刚放弃，马上又获得cpu时间片。
⑬、setpriority()
设置线程执行的级别，级别越大越有可能先执行完，1-10个级别，但不是绝对的
⑭、守护线程
设置线程为守护线程thread。setDaemon(true); 守护线程是一种特殊的线程，它的特性有陪伴的含义，当进程中不存在非守护线程了，则守护线程自动销毁。典型的守护线程是垃圾回收线程。
二、对象及变量的并发访问
①、方法内的变量不存在线程安全问题，因为方法内的变量私有的特性造成的
②synchronized方法与锁对象
关键字synchronized去的的锁都是对象锁，而不是把一段代码或者方法当做锁，所以那个线程先执行带synchronized关键字的方法，那个线程就持有该方法所属对象的锁Lock，那么其它线程只能呈等待状态，前提是多个线程访问的是同一个对象。如果多个线程访问多个对象，则JVM会创建多个锁。
调用关键字sychronized声明的方法一定是排队运行的。另外要牢牢记住“共享”这两个字，只有共享资源的读写访问才需要同步化，如果不是共享资源，那么根本就没有同步的必要。
③、脏读
（1）当A线程调用anyObeject对象加入synchronized关键字的X方法时，A线程就获得了X方法锁，更准确的讲，是获得了对象的锁，所以其他线程必须等A线程执行完毕才可以调用X方法，但B线程可以随意调用其他的非synchronized同步方法。
（2）当A线程调用anyObject对象加入sychronized关键字的X方法时，A线程就获得了X方法所在的对象的锁，所以其他线程必须等A线程执行完毕才可以调用X方法，而B线程如果嗲用声明了synchronized关键字的费X方法时，必须等A线程将X方法执行完，也就是释放对象锁后才可以调用。这时A线程已经执行了一个完整的任务，也就是说username和password这两个示例变量已经同时被赋值，不存在脏读的基本环境。
③synchronized锁重入
当存在父子类继承关系时，子类是完全可以通过“可重入锁”调用父类的同步方法的。
④、出现异常，锁自动释放
当一个线程执行的代码出现异常时，其所持有的锁会自动释放。
⑤、同步不具有继承性
当父类的方法加上synchronized以后，子类继承父类的方法以后，子类也要加synchronized才能同步。
⑥、关于synchronized代码块同步
在使用同步synchronized（this）代码块时需要注意的时，当一个线程访问object的一个synchronized（this）同步代码块时，其他线程对同一个object中所有其他synchronized（this）同步diamante块的访问将被阻塞，这说明synchronized使用的“对象监视器”是一个。
⑦、锁的使用
①synchronized(this)代码块锁定当前对象，监视器为当前对象
例：public void doLong(){
synchronized(this){
………………
}
}
②将任意对象作为对象监视器
例：public void doLong(){
synchronized（anything）{
…………
}
}
总结： synchronized同步方法和synchronized（this）同步代码块都能达到阻塞的状态，锁非this对象具有一定的优点：如果一个类中有很多个synchronized方法，这是虽然能实现同步，但是会受到阻塞，所以影响运行效率；但如果使用同步代码块锁非this对象，则异步的不与其他锁this同步方法争抢this锁，则可大大提高运行效率。可见使用“synchronized（非this对象x）同步代码块”格式进行同步操作时，对象监视器必须是同一个对象。如果不是同一个对象监视器，运行的结果就是异步调用了，就会有交叉运行。
③synchronized public static void printA（）{
………………
}
总结：关键字synchronized还可以应用在static静态方法上，如果这样写，那是对当前的*.java文件对应的Class类进行持锁。synchronized关键字加到static静态方法上是给Class类上锁，二synchronized关键字加到非static静态方法上是给对象上锁。
⑧、关于使用String作为锁产生的问题
String常量池会造成不同的变量，相同值时线程的锁会认为是同一把锁。使用对象锁可以改善这种状况。
⑨、死循环的举例
（1）同步方法间产生的死锁
解决办法：
⑩、volatile
关键字volatile的作用是强制从公共堆栈中取得变量的值，而不是从线程私有数据栈中取得变量的值。
（1）原先线程的运行模式
问题：这种结构会造成私有堆栈中的值和公有堆栈中的值不同步。
（2）使用volatile关键字的线程结构
通过使用volatile关键字，强制的从公共内存中读取变量的值。
（3）关于synchronized和volatile的对比
1）关键字volatile是线程同步的轻量级实现，所以volatile性能肯定比synchronized要好，并且volatile只能修饰于变量，而synchronized可以修饰方法，以及代码块。随着JDK新版本的发布，synchronized关键字在执行效率上得到很大提升，在开发中使用synchronized关键字的比率还是比较大的
2）多线程访问volatile不会发生阻塞，而synchronized会出现阻塞
3）volatile能保证数据的可见性，但不能保证原子性（因为它不具备同步性，也就不具备原子性）；而synchronized可以保证原子性，也可以间接保证可见性，因为它会将私有内存和公共内存中的数据做同步。
4）再次重申一下，关键字volatile解决的是变量在多个线程之间的可见性；而synchronized关键字解决的是多个线程之间访问资源的同步性。线程安全包含原子性和可见性两方面，java的同步机制都是围绕这两方面来确保线程安全的。
（4）volatile非原子的特性
volatile增加了实例变量在多个线程之间的可见性，但是它不具备同步性，所以也就不具备原子性。volatile主要使用的场合是在多个线程中可以感知实例变量被更改，并且可以获得最新的值使用，也就是用多线程读取共享变量时可以获取最新值使用。关键字volatile提示线程每次从共享内存中读取变量，而不是从私有内存中读取，这样就保证了同步数据的可见性。如果修改实例变量中的数据，比如i++，也就是i=i+1，则这样的操作其实并不是一个原子操作，也就是非线程安全的。操作过程：
1）从内存中取出i的值
2）计算i的值
3）将i的值写到内存中
在第2步计算值得时候，另外一个线程也修改i的值，这个时候就会出现脏读数据。解决的办法就是使用synchronized关键字。
图示演示volatile出现非线程安全的原因：
1）read和load阶段：从主存复制变量到当前线程工作内存
2）use和assign阶段：执行代码，改变共享变量值
3）store和write阶段：用工作内存数据刷新主存对应变量的值
在多线程环境中，use和assign是多次出现的，但这一操作并不是原子性，也就是在read和load之后，如果主内存count变量发生修改之后，线程工作内存中的值由于已经加载，不会产生对应的变化，也就是私有内存和公共内存中的变量不同步，所以计算出来的结果会和预期不一样，也就出现了非线程安全问题。对于用volatile修饰的变量，JVM虚拟机只是保证从主内存加载到线程工作内存的值时最新的，例如线程1和线程2在进行read和load的操作中，发现内存中count的值都是5，那么都会加载这个最新的值。也就是说，volatile关键字解决的事变量读时的可见性问题，但无法保证原子性，对于多个线程访问同一个实例变量需要加锁同步。
总结：关键字synchronized可以保证在同一时刻，只有一个线程可以执行某一方法或某一代码块。它包含两个特征：互斥性和可见性。同步synchronized不仅可以解决一个线程处于不一致的状态，还可以保证进入同步方法或同步代码块的每个线程，都能看到由同一个锁保护之前的修改效果。学习多线程并发，要着重“外练互斥，内修可见”，这是掌握多线程，学习多线程并发的重要技术点。
三、线程间的通信
①等待/通知机制的实
②方法wait()锁释放与notify()锁不释放
③锁释放的条件
④通过管道进行线程间通信：字节流、字节流
⑤方法join的使用
⑥方法join与异常
父线程异常，子线程继续运行
⑦方法join（long）和sleep（long）的区别
⑧ThreadLocal的使用
⑨生产者/消费者模式
四、Lock的使用
①使用多个Condition实现通知部分线程：正确用法
②公平锁与非公平锁
五、单例模式
①立即加载/饿汉模式
②延迟加载/懒汉模式
③延迟加载的缺点
④解决方法
（1）解决方案一
（2）解决方案二
（3）解决方案三
（4）解决方案四
注意1：不加volatile的双检测是线程不安全的
1. 传统的单例模式
大家都知道，单例模式主要分为：懒汉模式和饿汉模式。当我们在使用单例模式时，考虑到延迟加载，懒汉模式肯定是必须的。但是懒汉模式有一个很大的缺点，那就是线程不安全。我们为了解决这个问题，发明了双重检查锁定的写法，如下：
public class SingleTon {
private static SingleTon instance = null;
private SingleTon(){
}
public static SingleTon getInstance(){
if(instance == null){ // 1
synchronized (SingleTon.class){
if(instance == null){
instance = new SingleTon(); // 2
}
}
}
return instance;
}
}
如上代码所示，如果第一次检查instnace不为null的话，那么就不需要去获取锁来进行instance的初始化。因此，看上去可以大大的降低synchronized带来的性能开销。
双重检查锁定看上去非常的完美，但是却是一个错误的优化。当一个线程在执行到1时，读取到instance不为null时，instance引用的对象可能还没有初始化完毕。
2.问题的根源
在前面的代码中，instance = new SingleTon();是用来创建对象。这一行代码可以分解为如下三行伪代码：
memory = allocate(); //1.分配对象内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚分配的内存地址
因为2和3不存在数据依赖性，所以可能会被重排序。2和3重排序之后的执行顺讯可能如下：
memory = allocate(); //1.分配对象内存空间
instance = memory; //3.设置instance指向刚分配的内存地址，注意，此时对象还没有被初始化
ctorInstance(memory); //2.初始化对象
这里可能有人对重排序存在疑惑，如果想要理解什么是重排序，为什么要重排序等等原因，强烈推荐：方腾飞、魏鹏、程晓明三位老师的《Java 并发编程的艺术》。这里我就不对这部分进行展开，主要是自己太菜了，害怕对这部分的解释不好。
我们知道instance = new SingleTon()这一步可能会被重排序之后，现在我们来看看什么情况下能够导致问题。假设有两个线程，ThreadA和ThreadB，这两个线程都在调用SingleTone的getInstance方法来获取一个SingleTon的对象。执行顺序可能出现如下情况：
由于单线程内需要遵守intra-thread semantics,从而能保证ThreadA的执行结果不会被改变（所有线程在执行Java程序必须遵守intra-thread semantics，而intra-thread semantics保证所有的重排序在单线程里内，程序的执行结果不会被改变）。但是当ThreadB在按照上图的顺序在执行时，ThreadB将看到一个还没有被初始化的SingleTon对象。
从我们的程序代码中可以看出来，当instance = new SingleTon()发生了重排序，ThreadB在if(instance == null) 判断出false，接下来将访问instace所引用的对象，但是此时这个对象可能还没有被ThreadA初始化完毕。
上表就是对上面的流程图的一个总结。我们知道，最后ThreadB可能会返回一个为未初始化的对象。
在知道了问题的根源之后，我们可以想出两个办法来实现线程安全的延迟初始化。
1.不允许2和3重排序。
2.允许2和3重排序，但是不允许其他线程“看到”这个重排序。
3.解决方案
前面解释了双重检查锁定问题的根源，并且列出了两种解决思路。这里，我们将对这两种思路进行展开。
(1).基于volatile的解决方案
这个解决方案是非常的简单，只需要将我们之前的那个instance变量使用volatile关键字来修饰就行了。如下：
public class SingleTon {
private volatile static SingleTon instance = null;
private SingleTon(){
}
public static SingleTon getInstance(){
if(instance == null){ //1
synchronized (SingleTon.class){
if(instance == null){
instance = new SingleTon(); //2
}
}
}
return instance;
}
}
是不是非常的简单？当然我们这里的目的当然不是简单的实现解决方案，而是详细的解释为什么需要这样做。
memory = allocate(); //1.分配对象内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚分配的内存地址
由于instance是volatile变量，所以上面的代码中3相当于是对volatile变量进行写的操作，也就是所谓的volatile写。根据《Java 并发编程的艺术》的P43，我们知道对于一个volatile写，编译器会在volatile写的前面加入一个StoreStore内存屏障，用来防止前面的普通写与下面的volatile写进行重排序；在volatile写的后面加入一个StoreLoad屏障，主要是防止上面的volatile写与下面的可能有的volatile读/写进行重排序。如下图：
从而我们可以得出，instance = new SingleTon()指令执行顺序图：
所以，我们可以得出，只要instance被volatile修饰了，2和3就不能重排序。可以得出新的时序图：
这样，我们通过上面解决方案中第一个方案来保证了线程安全的延迟加载。
注意2：单例为什么要双重检查null
public class SingleTon {
privatestatic SingleTon singleTon = null;
publicSingleTon() {
// TODOAuto-generated constructor stub
}
publicstatic SingleTon getInstance(){
if(singleTon == null) {
synchronized(SingleTon.class) {
if(singleTon == null) {
singleTon =new SingleTon();
}
}
}
returnsingleTon;
}
}
考虑这样一种情况，就是有两个线程同时到达，即同时调用getInstance() 方法，
此时由于singleTon== null ，所以很明显，两个线程都可以通过第一重的 singleTon== null ，
进入第一重 if语句后，由于存在锁机制，所以会有一个线程进入 lock 语句并进入第二重 singleTon== null ，
而另外的一个线程则会在lock 语句的外面等待。
而当第一个线程执行完new SingleTon（）语句后，便会退出锁定区域，此时，第二个线程便可以进入lock 语句块，
此时，如果没有第二重singleTon== null 的话，那么第二个线程还是可以调用 new SingleTon（）语句，
这样第二个线程也会创建一个SingleTon实例，这样也还是违背了单例模式的初衷的，
所以这里必须要使用双重检查锁定。
细心的朋友一定会发现，如果我去掉第一重singleton == null ，程序还是可以在多线程下完好的运行的，
考虑在没有第一重singleton == null 的情况下，
当有两个线程同时到达，此时，由于lock 机制的存在，第一个线程会进入 lock 语句块，并且可以顺利执行 new SingleTon（），
当第一个线程退出lock 语句块时， singleTon 这个静态变量已不为 null 了，所以当第二个线程进入 lock 时，
还是会被第二重singleton == null 挡在外面，而无法执行 new Singleton（），
所以在没有第一重singleton == null 的情况下，也是可以实现单例模式的？那么为什么需要第一重 singleton == null呢？
这里就涉及一个性能问题了，因为对于单例模式的话，newSingleTon（）只需要执行一次就 OK 了，
而如果没有第一重singleTon == null 的话，每一次有线程进入getInstance（）时，均会执行锁定操作来实现线程同步，
这是非常耗费性能的，而如果我加上第一重singleTon == null 的话，
那么就只有在第一次，也就是singleTton ==null 成立时的情况下执行一次锁定以实现线程同步，
而以后的话，便只要直接返回Singleton 实例就 OK 了而根本无需再进入 lock语句块了，这样就可以解决由线程同步带来的性能问题了。
4159
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
