记一次Java面试问题点总结

引言

　　昨日接了一个阿里外包的电话面试，问了一些技术问题感觉到自己是真的菜，接触Java开发已经也有一段时间，技术方面说来惭愧，一直以来只是局限于框架工具的用法，也没有进行了解其实现的原理，更重要的是一直没有归纳和总结，这次把这些问题记录下来，相关的知识点也找了一些资料学习下。

问题

1. CountDownLanch的工作原理

实现原理：计数器的值由构造函数传入，并用它初始化AQS的state值。当线程调用await方法时会检查state的值是否为0，如果是就直接返回（即不会阻塞）；如果不是，将表示该节点的线程入列，然后将自身阻塞。当其它线程调用countDown方法会将计数器减1，然后判断计数器的值是否为0，当它为0时，会唤醒队列中的第一个节点，由于CountDownLatch使用了AQS的共享模式，所以第一个节点被唤醒后又会唤醒第二个节点，以此类推，使得所有因await方法阻塞的线程都能被唤醒而继续执行。

　　引用别人的博客里的一段话，详细请点击：Java并发包中CountDownLatch的工作原理、使用示例

题外话：

什么是 AQS（抽象的队列同步器） 
AbstractQueuedSynchronizer类如其名，抽象的队列式的同步器，AQS定义了一套多线程访问 共享资源的同步器框架，许多同步类实现都依赖于它，如常用的 ReentrantLock/Semaphore/CountDownLatch。 

它维护了一个 volatile int state（代表共享资源）和一个 FIFO 线程等待队列（多线程争用资源被 阻塞时会进入此队列）。这里 volatile 是核心关键词，具体 volatile 的语义，在此不述。state 的 访问方式有三种: getState() setState()  compareAndSetState()

AQS只是一个框架，具体资源的获取/释放方式交由自定义同步器去实现，AQS这里只定义了一个 接口，具体资源的获取交由自定义同步器去实现了（通过state的get/set/CAS)之所以没有定义成 abstract，是因为独占模式下只用实现 tryAcquire-tryRelease，而共享模式下只用实现 tryAcquireShared-tryReleaseShared。如果都定义成abstract，那么每个模式也要去实现另一模 式下的接口。不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实 现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/ 唤醒出队等），AQS已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：
1． isHeldExclusively()：该线程是否正在独占资源。只有用到condition才需要去实现它。

2． tryAcquire(int)：独占方式。尝试获取资源，成功则返回true，失败则返回false。

3． tryRelease(int)：独占方式。尝试释放资源，成功则返回true，失败则返回false。

4． tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0 表示成功，但没有剩余 可用资源；正数表示成功，且有剩余资源。

5． tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回 true，否则返回false。 

AQS定义两种资源共享方式

1.Exclusive独占资源 -ReentrantLock Exclusive（独占，只有一个线程能执行，如ReentrantLock）

2.Share共享资源 -Semaphore/CountDownLatch Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）。

3.实现独占和共享两种 方式，一般来说，自定义同步器要么是独占方法，要么是共享方式，他们也只需实现 tryAcquiretryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也支持自定义同步器 同时实现独占和共享两种方式，如ReentrantReadWriteLock

同步器的实现是ABS核心，以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程 lock()时，首先会调用compareAndSet(0,1)判断是否首次加锁，如果是首次则把当前线程记录下来，如果不是会调用 tryAcquire()中判断当前线程是否为独占线程，如果是独占该锁并将 state+1(可重入)。如果不是则返回false，此后，其他线程再 tryAcquire()时就会失 败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放 锁之前，A 线程自己是可以重复获取此锁的（state 会累加），这就是可重入的概念。但要注意， 获取多少次就要释放多么次，这样才能保证state是能回到零态的。

以CountDownLatch以例，任务分为N个子线程去执行，state也初始化为N（注意N要与 线程个数一致）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state 会CAS减1。等到所有子线程都执行完后(即state=0)，会unpark()主调用线程，然后主调用线程 就会从await()函数返回，继续后余动作。

2. 说一下自旋锁的原理

如果持有锁的线程能在很短的时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换，它们只需要等一等（自旋），等待锁释放之后即可立即获取锁，这样避免了用户线程和内核切换的消耗

线程自旋是需要消耗 cup 的，说白了就是让 cup 在做无用功，如果一直获取不到锁，那线程 也不能一直占用cup自旋做无用功，所以需要设定一个自旋等待的最大时间。
如果持有锁的线程执行的时间超过自旋等待的最大时间扔没有释放锁，就会导致其它争用锁 的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。

自旋锁的优缺点
自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来 说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会 导致线程发生两次上下文切换！
但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合 使用自旋锁了，因为自旋锁在获取锁前一直都是占用 cpu 做无用功，占着 XX 不 XX，同时有大量 线程在竞争一个锁，会导致获取锁的时间很长，线程自旋的消耗大于线程阻塞挂起操作的消耗， 其它需要cup的线程又不能获取到cpu，造成cpu的浪费。所以这种情况下我们要关闭自旋锁；

3. synchronized中类锁和对象锁的区别

　这么基础的一个问题我竟然遗忘了。。因为之前记的是锁static方法和非static方法的区别，其实锁static方法就相当于锁类class，因为static方法是所有的类共享的，类锁是锁当前类的所有实例，对象锁是锁当前实例对象，详细的引入别人的博客：Java锁Synchronized对象锁和类锁的区别

4. volatile关键字的作用

     问：说下项目中用到的设计模式

答：单例模式、责任链模式、工程模式、模板模式等等

问：那你说下你们平常单例模式怎么实现的

答：我们用的是双向检查

问：你们双向检查有用到volatile吧，那你说下这个关键字有什么作用

答：它可以用来保证线程每次获取的对象都是最新状态

     问：除此之外还有什么作用

答: 卒

　 真的是