一、接口、抽象类、类的区别

       1 支持多重继承：接口支持；抽象类不支持；类不支持；
       2 支持抽象函数：接口语义上支持；抽象类支持；类不支持；
       3 允许函数实现：接口不允许；抽象类支持；类允许；
       4 允许实例化：接口不允许；抽象类不允许；类允许；
       5 允许部分函数实现：接口不允许；抽象类允许；类不允许。
       6 定义的内容：接口中只能包括public函数以及public static final常量；抽象类与类均无任何限制。
       7 使用时机：当想要支持多重继承，或是为了定义一种类型请使用接口；当打算提供带有部分实现的“模板”类，而将一些功能需要延迟实现请使用抽象类；当你打算提供完整的具体实现请使用类。

二、ReentrantLock和synchronized的区别

       ReentrantLock是Lock的实现类，是一个互斥的同步器，在多线程高竞争条件下，ReentrantLock比synchronized有更加优异的性能表现。

1 用法比较

       Lock使用起来比较灵活，但是必须有释放锁的配合动作
       Lock必须手动获取与释放锁，而synchronized不需要手动释放和开启锁
       Lock只适用于代码块锁，而synchronized可用于修饰方法、代码块等

2 特性比较

       ReentrantLock的优势体现在：具备尝试非阻塞地获取锁的特性：当前线程尝试获取锁，如果这一时刻锁没有被其他线程获取到，则成功获取并持有锁能被中断地获取锁的特性：与synchronized不同，获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁会被释放超时获取锁的特性：在指定的时间范围内获取锁；如果截止时间到了仍然无法获取锁，则返回。

3 注意事项

       在使用ReentrantLock类的时，一定要注意三点：在finally中释放锁，目的是保证在获取锁之后，最终能够被释放；不要将获取锁的过程写在try块内，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故被释放；ReentrantLock提供了一个newCondition的方法，以便用户在同一锁的情况下可以根据不同的情况执行等待或唤醒的动作。

三、synchronized的实现原理

       synchronized修饰的代码块通过反编译发现其实现原理是由一对儿monitorenter/monitorexit指令实现的。示例代码如下：

synchronized (this) {
       // todo list
       // …
    }

       synchronized代码块反编译输出结果：

    11: astore_1
    12: monitorenter
    …
    50: monitorexit

       在Java 6之前，Monitor的实现完全是依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作。现代的（Oracle）JDK中，JVM对此进行了大刀阔斧地改进，提供了三种不同的Monitor实现，也就是常说的三种不同的锁：偏斜锁（Biased Locking）、轻量级锁和重量级锁，大大改进了其性能。所谓锁的升级、降级，就是JVM优化synchronized运行的机制，当JVM检测到不同的竞争状况时，会自动切换到适合的锁实现，这种切换就是锁的升级、降级。当没有竞争出现时，默认会使用偏斜锁。JVM会利用CAS操作（compare and swap），在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。如果有另外的线程试图锁定某个已经被偏斜过的对象，JVM就需要撤销（revoke）偏斜锁，并切换到轻量级锁实现。轻量级锁依赖CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。有的观点认为Java不会进行锁降级。实际上锁降级确实是会发生的，当JVM进入安全点（SafePoint）的时候，会检查是否有闲置的Monitor，然后试图进行降级。

为什么我们需要读写锁（ReadWriteLock）等其他锁呢？

       这是因为，虽然ReentrantLock和synchronized简单实用，但是行为上有一定局限性，通俗点说就是“太霸道”，要么不占，要么独占。实际应用场景中，有的时候不需要大量竞争的写操作，而是以并发读取为主，如何进一步优化并发操作的粒度呢？Java并发包提供的读写锁等扩展了锁的能力，它所基于的原理是多个读操作是不需要互斥的，因为读操作并不会更改数据，所以不存在互相干扰。而写操作则会导致并发一致性的问题，所以写线程之间、读写线程之间，需要精心设计的互斥逻辑。下面是一个基于读写锁实现的数据结构，当数据量较大，并发读多、并发写少的时候，能够比纯同步版本凸显出优势。

    public class RWSample {
        private final Map<String, String> m = new TreeMap<>();
        private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
        private final Lock r = rwl.readLock();
        private final Lock w = rwl.writeLock();
        public String get(String key) {
            r.lock();
            System.out.println("读锁锁定！");
            try {
                return m.get(key);
            } finally {
                r.unlock();
            }
        }
    
        public String put(String key, String entry) {
            w.lock();
        System.out.println("写锁锁定！");
                try {
                    return m.put(key, entry);
                } finally {
                    w.unlock();
                }
            }
        // …
        }

       在运行过程中，如果读锁试图锁定时，写锁是被某个线程持有，读锁将无法获得，而只好等待对方操作结束，这样就可以自动保证不会读取到有争议的数据。读写锁看起来比synchronized的粒度似乎细一些，但在实际应用中，其表现也并不尽如人意，主要还是因为相对比较大的开销。所以，JDK在后期引入了StampedLock，在提供类似读写锁的同时，还支持优化读模式。优化读基于假设，大多数情况下读操作并不会和写操作冲突，其逻辑是先试着读，然后通过validate方法确认是否进入了写模式，如果没有进入，就成功避免了开销；如果进入，则尝试获取读锁。请参考我下面的样例代码。

    public class StampedSample {
        private final StampedLock sl = new StampedLock();
    
        void mutate() {
            long stamp = sl.writeLock();
            try {
                write();
            } finally {
                sl.unlockWrite(stamp);
            }
        }
    
        Data access() {
            long stamp = sl.tryOptimisticRead();
            Data data = read();
            if (!sl.validate(stamp)) {
                stamp = sl.readLock();
                try {
                    data = read();
                } finally {
                    sl.unlockRead(stamp);
                }
            }
            return data;
        }
        // …
    }

       注意，这里的writeLock和unLockWrite一定要保证成对调用。你可能很好奇这些显式锁的实现机制，Java并发包内的各种同步工具，不仅仅是各种Lock，其他的如Semaphore、CountDownLatch，甚至是早期的FutureTask等，都是基于一种AQS框架。
       自旋锁:竞争锁的失败的线程，并不会真实的在操作系统层面挂起等待，而是JVM会让线程做几个空循环(基于预测在不久的将来就能获得)，在经过若干次循环后，如果可以获得锁，那么进入临界区，如果还不能获得锁，才会真实的将线程在操作系统层面进行挂起。适用场景:自旋锁可以减少线程的阻塞，这对于锁竞争不激烈，且占用锁时间非常短的代码块来说，有较大的性能提升，因为自旋的消耗会小于线程阻塞挂起操作的消耗。如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功，线程自旋的消耗大于线程阻塞挂起操作的消耗，造成cpu的浪费。