Java多线程相关

1、Java中的线程调度算法

• 一种是分时调度，让所有的线程轮流获得CPU的使用权，并且平均分配每个线程占用的CPU时间片。
• 另一种是抢占式任务调度，可以让优先级高的优先执行，如果优先级相等就随机选一个执行。

线程调度器： 是一个操作系统服务，负责为一个可运行状态的线程分配CPU时间片。一旦创建一个线程并启动它，它的执行便依赖于线程调度器的实现。

时间分片 是指可用的CPU时间片分配给可用的就绪线程的过程

2、sleep()函数与wait()函数的区别

• sleep()不会释放锁，是Thread类的方法；而wait()会释放锁，是Object类的方法。
• sleep()常用于暂停执行；而wait()常和notify()、notifyAll()函数结合用在线程间通信。
• sleep()之后线程会自动苏醒，而wait()需要使用notify()或notifyAll()函数唤醒。

3、wait()、notify()、notifyAll()定义在Object类里面的原因

Java中任何对象都可以作为锁，wait()、notify()等方法用于等待对象的锁和唤醒线程，在Thread类里面并没有设置可供任何对象使用的锁，所以任意对象调用放在了Object类中。既然是线程放弃对象的锁wait()方法也可以放在Thread类中，新建的线程通过继承Thread类也不需要重写wait()方法，这种设计不是不能实现，而是管理起来很复杂，因为一个线程可能持有很多锁，在释放锁的时候到底是释放哪一个呢，因此上述方法定义在了Object类中。

4、常用方法

• yield()，让出CPU使用权，是现成重新进入就绪状态，但是不能保证其他线程一定会执行，下一次也可能是此线程抢到CPU执行权。
• join()，等待该线程终止。
• interrupt，将此线程的状态设置为中断，但并不会终止线程。
• interrupted，查看当前中断信号是true还是false并清除中断信号，如果一个线程被中断第一次调用此方法返回true，之后再次调用会返回false。
• isInterrupted，查看中断信号是true还是false。

sleep()和yield方法设置为静态的原因是表示对当前正在运行的线程进行操作，对处于其他状态的线程操作无意义。

5、多线程间的通信方式

• 使用synchronized加锁的的wait()、notify()、notifyAll()等待唤醒机制；
• ReentrantLock类加锁的Condition类的await()、signal()、signalAll()方法。

6、重排序

在执行程序时为了提供性能，编译器和处理器通常会对指令进行重排序，排序的依据如下：

• 在单线程环境下不影响运行结果；
• 具有数据依赖的指令不允许重排序

as-if-serial规则和happens-before规则

• as-if-serial，保证单线程条件下的执行结果不被改变；
• happens-before，如果一个操作happens-before另一个操作，那么第一个操作的执行结果对第二个操作可见，而且第一个操作发生在第二个操作之前

其实只要不改变程序的执行结果(单线程程序和正确同步的多线程程序)，编译器和处理器怎么优化都行

7、synchronized关键字

同步代码块底层实现：
synchronized底层实现是monitor对象，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，释放锁时monitorexit指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异步退出释放锁。

同步方法块底层实现：
同步方法底层其实和同步代码块一样使用了monitor对象，但是它是隐式的使用，同步方法底层有个ACC_SYNCHRONIZED 标识符。当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。

synchronized可重入的原理：
简单来说就是synchronized维护了一个计数器，当获取锁时就将计数器加一，释放锁时就将计数器减一，当计数器为0的时候表示该锁未被任何线程所持有，可以被其他线程竞争获取。

8、自旋锁

线程的阻塞和唤醒会导致CPU在用户态和内核态之间的切换，频繁的阻塞和唤醒会导致CPU切换状态频繁，对CPU来说是个很大的消耗。在许多应用上面对象锁的锁状态持续时间都很短，为这一段短的时间频繁的切换CPU状态是非常不值得的，因此引入了自旋。

所谓自选就是指当线程获取某个锁是，如果该锁已被其他线程所占用，此线程会一直循环检测锁是否释放，而不会进入挂起或唤醒状态。自旋锁虽然避免了线程切换带来的开销，但是却占用了CPU时间，如果持有锁的线程很快就释放好了锁那么自旋的效率就很好，反之就是白白浪费了资源而且也没有做任何有意义的工作，JDK中设置了自选的次数(10次)，如果超过这个次数就挂起。

JDK1.6之后再自选的基础上进行了优化，这就是自适应的自旋锁，也就是说自选的次数不是固定的，是根据情况决定的。
线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。

9、Java内存模型JMM

JMM三大特性：

• 原子性
• 可见性
• 有序性

关于JMM的同步规定：

• 线程解锁前必须把共享变量的值刷新到主内存中；
• 线程加锁前必须从主内存中读取最新的共享变量的值；
• 加锁与解锁使用的是同一把锁。
  
  每个线程都有一个本地内存，保存主内存中的共享变量的副本。

10、CAS与其带来的问题

CAS，Compare And Swap，比较并交换，也就是说当内存位置V与原数据预期值A相匹配，就将内存中的值更新为新值B，否则不做交换。

CAS存在的问题

• ①、ABA问题，比如说一个线程 one 从内存位置 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且 two 进行了一些操作变成了 B，然后 two 又将 V 位置的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中仍然是 A，然后 one 操作成功。尽管线程 one 的 CAS 操作成功，但可能存在潜藏的问题。从 Java1.5 开始 JDK 的 atomic包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。
• ②、循环时间开销大，对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较大，从而浪费更多的 CPU 资源，效率低于 synchronized。
• ③、只能保证一个共享变量的原子操作，当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁。

11、volatile

volatile可以保证可见性并禁止指令重排序，volatile提供 happens-before的保证，确保一个线程的修改对其他线程是可见的，但volatile并不能保证原子性，当一个共享变量倍volatile修饰时，线程修改共享变量之后会被立即刷新到主内存中。

volatile可与CAS结合起来保证原子性，具体应用是java.util.concurrent.atomic包下的如AtomicInteger类等。

12、公平锁与非公平锁

公平锁要维护一个队列，后来的线程要加锁，即使锁空闲，也要先检查有没有其他线程在 wait，如果有自己要挂起，加到队列后面，然后唤醒队列最前面的线程。这种情况下相比较非公平锁多了一次挂起和唤醒

说得再详细一点，就是对于非公平锁和公平锁，这两种锁都有等待队列，但是区别在于非公平锁允许线程不先出入队而是先尝试获得锁，这一点上公平锁需要扫描等待队列，源码上也直接反映了这一点。去掉这个功能的话公平锁和非公平锁也无甚差异。