2019java后台开发面试题3----java基础
java基础数据类型取值范围？
整型
其中byte、short、int、long都是表示整数的，只不过他们的取值范围不一样
byte的取值范围为-128~127，占用1个字节（-2的7次方到2的7次方-1）
short的取值范围为-32768~32767，占用2个字节（-2的15次方到2的15次方-1）
int的取值范围为（-2147483648~2147483647），占用4个字节（-2的31次方到2的31次方-1）
long的取值范围为（-9223372036854774808~9223372036854774807），占用8个字节（-2的63次方到2的63次方-1）
面向对象的特性？（封装继承多态）如何体现出来？
#一、继承
***1、概念：***继承是类与类的一种关系，是一种“is a”的关系。比如“狗”继承“动物”，这里动物类是狗类的父类或者基类，狗类是动物类的子类或者派生类。
2、java中的继承是单继承，即一个类只有一个父类
3、优点：子类拥有父类的所有属性和方法（除了private修饰的属性不能拥有）从而实现了实现代码的复用
4、语法规则，只要在子类加上extends关键字继承相应的父类就可以了
class 子类 extends 父类
栗子：class Dog extends Animal{…}
***5、方法的重写：***子类不满意父类的方法时，可以编写自己的继承方法，这种方式称为方法的重写，并用@override注解来标注该方法为重写方法，该注解带有识别功能，能辨识你的方法是否为重写方法，否则在编译阶段就会报错
重载和重写的区别：
方法重载：在同一个类中处理不同数据的多个相同方法名的多态手段。
方法重写：相对继承而言，子类中对父类已经存在的方法进行区别化的修改。
6、final关键字
final有“最终的”含义：
1）final 修饰类，则该类不允许被继承
2）final 修饰方法，则该方法不允许被覆盖(重写)
3）final 修饰属性，则该类的该属性不会进行隐式的初始化，所以 该final 属性的初始化属性必须有值，或在构造方法中赋值(但只能选其一，且必须选其一，因为没有默认值！)，且初始化之后就不能改了，只能赋值一次
4）final 修饰变量，则该变量的值只能赋一次值，在声明变量的时候才能赋值，即变为常量
######7、super关键字
在对象的内部使用可代表父类对象
1）访问父类属性：super.fatherProperty
2）访问父类方法：super.fatherMethod()
super的应用：
1)首先我们知道子类的构造的过程当中必须调用父类的构造方法。其实这个过程已经隐式地使用了我们的super关键字
2)这是因为如果子类的构造方法中没有显示调用父类的构造方法，则系统默认调用父类无参的构造方法。那么如果自己用super关键字在子类里调用父类的构造方法，则必须在子类的构造方法中的第一行
3)注意：如果子类构造方法中既没有显示调用父类的构造方法，而父类没有无参的构造方法，则编译出错。
4）如果父类没有显示声明父类的无参的构造方法，系统会自动生成一个无参构造方法，但是如果声明了一个有参构造方法而没有声明无参构造方法，这时系统不会自动默认生成一个无参构造方法，此时称为父类没有无参构造方法。
######8、Object类
Object类是所有类的父类，如果一个类没有使用extends关键字明确标识继承另一个类，那么这个类默认继承Object类。
Object类中的方法，适合所有子类
#二、封装
1、封装概念：
将类的某些信息隐藏在类内部，不允许外部程序直接访问，而是通过该类提供的方法来实现对隐藏信息的操作和访问。
2、封装优点：
只能通过规定的方法访问数据。
隐藏类的实例细节，方便修改和实现。
3、封装的实现步骤
属性可见性设置为private–>创建用于读写的getter/setter方法–>在getter/setter方法中加入属性控制语句
4、注意：对封装的属性不一定要通过get/set方法，其他方法也可以对封装的属性进行操作。当然最好使用get/set方法，比较标准。
######5、访问修饰符(访问权限最大范围)
private：本类
default：包内
protected：包内、子类
public：包内、子类、其它
######6、this关键字
1）this关键字代表当前对象
this.属性 操作当前对象的属性
this.方法 调用当前对象的方法。
2）封装对象的属性的时候，经常会使用this关键字
3）当getter和setter函数参数名和成员函数名重合的时候，可以使用this区别
######7、内部类
内部类（ Inner Class ）就是定义在另外一个类里面的类。与之对应，包含内部类的类被称为外部类。
内部类的主要作用：
1）内部类提供了更好的封装，可以把内部类隐藏在外部类之内，不允许同一个包中的其他类访问该类。
2）内部类的方法可以直接访问外部类的所有数据，包括私有的数据。
3）内部类所实现的功能使用外部类同样可以实现，只是有时使用内部类更方便。
内部类可分为以下几种：
成员内部类
静态内部类
方法内部类
匿名内部类
#三、多态
多态就是对象的多种形态,什么对象才会具有多种形态？原子性的事物没有多种形态，是什么就是什么，某一类事物，是概念上事物，不指
######1、引用多态
父类的引用可以指向本类的对象，也可以指向子类的对象，反过来行不通。
######2.方法多态
创建本类对象调用的方法为本类方法，创建子类对象，调用的方法为子类重写的方法或者继承的方法。
【集合】
4.Map下Hashmap、TreeMap的区别？
就是我们平时说的键值对。
HashMap通过hashcode对其内容进行快速查找，而 TreeMap中所有的元素都保持着某种固定的顺序，如果你需要得到一个有序的结果你就应该使用TreeMap（HashMap中元素的排列顺序是不固定的）。
HashMap 非线程安全 TreeMap 非线程安全
线程安全
在Java里，线程安全一般体现在两个方面：
1、多个thread对同一个java实例的访问（read和modify）不会相互干扰，它主要体现在关键字synchronized。如ArrayList和Vector，HashMap和Hashtable
（后者每个方法前都有synchronized关键字）。如果你在interator一个List对象时，其它线程remove一个element，问题就出现了。
2、每个线程都有自己的字段，而不会在多个线程之间共享。它主要体现在java.lang.ThreadLocal类，而没有Java关键字支持，如像static、transient那样。
1.AbstractMap抽象类和SortedMap接口
AbstractMap抽象类：(HashMap继承AbstractMap)覆盖了equals()和hashCode()方法以确保两个相等映射返回相同的哈希码。如果两个映射大小相等、包含同样的键且每个键在这两个映射中对应的值都相同，则这两个映射相等。映射的哈希码是映射元素哈希码的总和，其中每个元素是Map.Entry接口的一个实现。因此，不论映射内部顺序如何，两个相等映射会报告相同的哈希码。
SortedMap接口：（TreeMap继承自SortedMap）它用来保持键的有序顺序。SortedMap接口为映像的视图(子集)，包括两个端点提供了访问方法。除了排序是作用于映射的键以外，处理SortedMap和处理SortedSet一样。添加到SortedMap实现类的元素必须实现Comparable接口，否则您必须给它的构造函数提供一个Comparator接口的实现。TreeMap类是它的唯一一份实现。
2.两种常规Map实现
HashMap：基于哈希表实现。使用HashMap要求添加的键类明确定义了hashCode()和equals()[可以重写hashCode()和equals()]，为了优化HashMap空间的使用，您可以调优初始容量和负载因子。
(1)HashMap(): 构建一个空的哈希映像
(2)HashMap(Map m): 构建一个哈希映像，并且添加映像m的所有映射
(3)HashMap(int initialCapacity): 构建一个拥有特定容量的空的哈希映像
(4)HashMap(int initialCapacity, float loadFactor): 构建一个拥有特定容量和加载因子的空的哈希映像
TreeMap：基于红黑树实现。TreeMap没有调优选项，因为该树总处于平衡状态。红黑树---平衡的二查找树
(1)TreeMap():构建一个空的映像树
(2)TreeMap(Map m): 构建一个映像树，并且添加映像m中所有元素
(3)TreeMap(Comparator c): 构建一个映像树，并且使用特定的比较器对关键字进行排序
(4)TreeMap(SortedMap s): 构建一个映像树，添加映像树s中所有映射，并且使用与有序映像s相同的比较器排序
3.两种常规Map性能
HashMap：适用于在Map中插入、删除和定位元素。
Treemap：适用于按自然顺序或自定义顺序遍历键(key)。
4.总结
HashMap通常比TreeMap快一点(树和哈希表的数据结构使然)，建议多使用HashMap，在需要排序的Map时候才用TreeMap。
3.Map、List下哪些类是线程安全的？（常考）
Vector：就比Arraylist多了个同步化机制（线程安全）。
Hashtable：就比Hashmap多了个线程安全。
ConcurrentHashMap:是一种高效但是线程安全的集合，取代hashtable
Stack：栈，也是线程安全的，继承于Vector。
1.Hashmap如何解决哈希冲突？与HashTable有何不同？
HashMap的底层主要是基于数组和链表来实现的，它之所以有相当快的查询速度主要是因为它是通过计算散列码来决定存储的位置。HashMap中主要是通过key的hashCode来计算hash值的，只要hashCode相同，计算出来的hash值就一样。如果存储的对象对多了，就有可能不同的对象所算出来的hash值是相同的，这就出现了所谓的hash冲突。学过数据结构的同学都知道，解决hash冲突的方法有很多，HashMap底层是通过链表来解决hash冲突的。
图中，紫色部分即代表哈希表，也称为哈希数组，数组的每个元素都是一个单链表的头节点，链表是用来解决冲突的，如果不同的key映射到了数组的同一位置处，就将其放入单链表中。
区别
HashMap和Hashtable都实现了Map接口，但决定用哪一个之前先要弄清楚它们之间的分别。主要的区别有：线程安全性，同步(synchronization)，以及速度。
- HashMap几乎可以等价于Hashtable，除了HashMap是非synchronized的，并可以接受null(HashMap可以接受为null的键值(key)和值(value)，而Hashtable则不行)。
- HashMap是非synchronized，而Hashtable是synchronized，这意味着Hashtable是线程安全的，多个线程可以共享一个Hashtable；而如果没有正确的同步的话，多个线程是不能共享HashMap的。Java 5提供了ConcurrentHashMap，它是HashTable的替代，比HashTable的扩展性更好。
- 另一个区别是HashMap的迭代器(Iterator)是fail-fast迭代器，而Hashtable的enumerator迭代器不是fail-fast的。所以当有其它线程改变了HashMap的结构（增加或者移除元素），将会抛出ConcurrentModificationException，但迭代器本身的remove()方法移除元素则不会抛出ConcurrentModificationException异常。但这并不是一个一定发生的行为，要看JVM。这条同样也是Enumeration和Iterator的区别。
- 由于Hashtable是线程安全的也是synchronized，所以在单线程环境下它比HashMap要慢。如果你不需要同步，只需要单一线程，那么使用HashMap性能要好过Hashtable。
- HashMap不能保证随着时间的推移Map中的元素次序是不变的。
- HashMap可以通过下面的语句进行同步：
Map m = Collections.synchronizeMap(hashMap);
【多线程】
怎么解决多线程并发问题？
对共享资源-----------------------------加锁------------------------------------修改--------------------------释放锁
对共享资源枷锁，保证任何时刻只有一个线程可以获得对同步监视器的锁定，当同步方法执行完成后，该线程会释放对该同步监视器的锁定
解决多线程的并发安全问题，java无非就是加锁，具体就是两个方法
(1) Synchronized(java自带的关键字)
(2) lock 可重入锁
（1）synchronized 是互斥锁；
（2）ReentrantLock 顾名思义 ：可重入锁
（3）ReentrantReadWriteLock :读写锁
Java中锁机制；
我们看到了Lock和synchronized都能正常的保证数据的一致性，也看到了Lock的优势，那究竟他们是什么原理来保障的呢？今天我们就来探讨下Java中的锁机制！
Synchronized是基于JVM来保证数据同步的，而Lock则是在硬件层面，依赖特殊的CPU指令实现数据同步的，那究竟是如何来实现的呢？我们一一看来！
一、synchronized的实现方案
synchronized比较简单，语义也比较明确，尽管Lock推出后性能有较大提升，但是基于其使用简单，语义清晰明了，使用还是比较广泛的，其应用层的含义是把任意一个非NULL的对象当作锁。当synchronized作用于方法时，锁住的是对象的实例(this)，当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久带，因此静态方法锁相当于类的一个全局锁，当synchronized作用于一个对象实例时，锁住的是对应的代码块。在Sun的HotSpot JVM实现中，其实synchronized锁还有一个名字：对象监视器。
当多个线程一起访问某个对象监视器的时候，对象监视器会将这些请求存储在不同的容器中。
1、 Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中
2、 Entry List：Contention List中那些有资格成为候选资源的线程被移动到Entry List中
3、 Wait Set：哪些调用wait方法被阻塞的线程被放置在这里
4、 OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为OnDeck
5、 Owner：当前已经获取到所资源的线程被称为Owner
6、 !Owner：当前释放锁的线程
下图展示了他们之前的关系
ContentionList并不是真正意义上的一个队列。仅仅是一个虚拟队列，它只有Node以及对应的Next指针构成，并没有Queue的数据结构。每次新加入Node会在队头进行，通过CAS改变第一个节点为新增节点，同时新增阶段的next指向后续节点，而取数据都在队列尾部进行。
JVM每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList会被大量的并发线程进行CAS访问，为了降低对尾部元素的竞争，JVM会将一部分线程移动到EntryList中作为候选竞争线程。Owner线程会在unlock时，将ContentionList中的部分线程迁移到EntryList中，并指定EntryList中的某个线程为OnDeck线程（一般是最先进去的那个线程）。Owner线程并不直接把锁传递给OnDeck线程，而是把锁竞争的权利交个OnDeck，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在JVM中，也把这种选择行为称之为“竞争切换”。
OnDeck线程获取到锁资源后会变为Owner线程，而没有得到锁资源的仍然停留在EntryList中。如果Owner线程被wait方法阻塞，则转移到WaitSet队列中，直到某个时刻通过notify或者notifyAll唤醒，会重新进去EntryList中。
处于ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux内核下采用pthread_mutex_lock内核函数实现的）。该线程被阻塞后则进入内核调度状态，会导致系统在用户和内核之间进行来回切换，严重影响锁的性能。为了缓解上述性能问题，JVM引入了自旋锁。原理非常简单，如果Owner线程能在很短时间内释放锁资源，那么哪些等待竞争锁的线程可以稍微等一等（自旋）而不是立即阻塞，当Owner线程释放锁后可立即获取锁，进而避免用户线程和内核的切换。但是Owner可能执行的时间会超过设定的阈值，争用线程在一定时间内还是获取不到锁，这是争用线程会停止自旋进入阻塞状态。基本思路就是先自旋等待一段时间看能否成功获取，如果不成功再执行阻塞，尽可能的减少阻塞的可能性，这对于占用锁时间比较短的代码块来说性能能大幅度的提升！
但是有个头大的问题，何为自旋？其实就是执行几个空方法，稍微等一等，也许是一段时间的循环，也许是几行空的汇编指令，其目的是为了占着CPU的资源不释放，等到获取到锁立即进行处理。但是如何去选择自旋的执行时间呢？如果自旋执行时间太长，会有大量的线程处于自旋状态占用CPU资源，进而会影响整体系统的性能。因此自旋的周期选的额外重要！
JVM对于自旋周期的选择，基本认为一个线程上下文切换的时间是最佳的一个时间，同时JVM还针对当前CPU的负荷情况做了较多的优化
1、 如果平均负载小于CPUs则一直自旋
2、 如果有超过(CPUs/2)个线程正在自旋，则后来线程直接阻塞
3、 如果正在自旋的线程发现Owner发生了变化则延迟自旋时间（自旋计数）或进入阻塞
4、 如果CPU处于节电模式则停止自旋
5、 自旋时间的最坏情况是CPU的存储延迟（CPU A存储了一个数据，到CPU B得知这个数据直接的时间差）
6、 自旋时会适当放弃线程优先级之间的差异
Synchronized在线程进入ContentionList时，等待的线程就通过自旋先获取锁，如果获取不到就进入ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占OnDeck线程的锁资源。
在JVM6以后还引入了一种偏向锁，主要用于解决无竞争下面锁的性能问题。我们首先来看没有这个会有什么样子的问题。
现在基本上所有的锁都是可重入的，即已经获取锁的线程可以多次锁定/解锁监视对象，但是按照之前JVM的设计，每次加锁解锁都采用CAS操作，而CAS会引发本地延迟（下面会讲原因），因此偏向锁希望线程一旦获取到监视对象后，之后让监视对象偏向这个锁，进而避免多次CAS操作，说白了就是设置了一个变量，发现是这个线程过来的就避免再走加锁解锁流程。
那CAS为什么会引发本地延迟呢？这要从多核处（SMP）理架构说起（前面有提到过--JVM内存模型），下图基本上表明了多核处理的架构
多核CPU会共享一条系统总线，靠总线和主存通讯，但是每个CPU又有自己的一级缓存，而CAS是一条原子指令，其作用是让CPU比较，如果相同则进行数据更新，而这些是基于硬件实现的（JVM只是封装了硬件的汇编调用，AtomicInteger其实是通过调用这些封装后的接口实现的）。多核运算时，由于线程切换，很有可能第二次取值是在另外一核CPU上执行的。假设Core1和Core2把对应的某个值加载到自己的一级缓存时，某个时刻，core1更新了这个数据并通过总线通知主存，此时core2的一级缓存中的数据就失效了，他需要从主存中重新加载一次到一级缓存中，大家通过总线通讯被称之为一致性流量，总线的通讯能力有限，当缓存一致性流量过大时，总线会成为瓶颈，而当Core1和Core2的数据再次一致时，被称为缓存一致性！
而CAS要保证数据的一致性，恰好会引发比较多的一致性流量，如果有很多线程共享一个对象，当某个线程成功执行一次CAS时会引发总线风暴，这就是本地延迟，而偏向锁就是为了消除CAS，降低Cache一致性流量！
当然并不是所有的CAS都会引发总线风暴，这和Cache一致性协议有关系的。但是偏向锁的引入却带来了另外一个问题，在很多线程竞争使用中，如果一个线程持有偏向锁，另外一个线程想争用偏向对象，拥有者想释放这个偏向锁，释放会带来额外的性能开销，但是总体来说偏向锁带来的好处还是大于CAS的代价的。
二、Lock的实现
与synchronized不同的是，Lock书纯Java实现的，与底层的JVM无关。在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReadWriteLock（实现类ReentrantReadWriteLock），其实现都依赖java.util.concurrent.AbstractQueuedSynchronizer类（简称AQS），实现思路都大同小异，因此我们以ReentrantLock作为讲解切入点。
分析之前我们先来花点时间看下AQS。AQS是我们后面将要提到的CountDownLatch/FutureTask/ReentrantLock/RenntrantReadWriteLock/Semaphore的基础，因此AQS也是Lock和Excutor实现的基础。它的基本思想就是一个同步器，支持获取锁和释放锁两个操作。
获取锁：首先判断当前状态是否允许获取锁，如果是就获取锁，否则就阻塞操作或者获取失败，也就是说如果是独占锁就可能阻塞，如果是共享锁就可能失败。另外如果是阻塞线程，那么线程就需要进入阻塞队列。当状态位允许获取锁时就修改状态，并且如果进了队列就从队列中移除。
while(synchronization state does not allow acquire){
enqueue current thread if not already queued;
possibly block current thread;
}
dequeue current thread if it was queued;
释放锁:这个过程就是修改状态位，如果有线程因为状态位阻塞的话，就唤醒队列中的一个或者更多线程。
update synchronization state;
if(state may permit a blocked thread to acquire)
unlock one or more queued threads;要支持上面两个操作就必须有下面的条件：
1、 状态位必须是原子操作的
2、 阻塞和唤醒线程
3、 一个有序的队列，用于支持锁的公平性
怎么样才能满足这几个条件呢？
1、 原子操作状态位，前面我们已经提到了，实际JDK中也是通过一个32bit的整数位进行CAS操作来实现的。
2、 阻塞和唤醒，JDK1.5之前的API中并没有阻塞一个线程，然后在将来的某个时刻唤醒它（wait/notify是基于synchronized下才生效的，在这里不算），JDK5之后利用JNI在LockSupport 这个类中实现了相关的特性！
3、 有序队列：在AQS中采用ＣＬＨ队列来解决队列的有序问题。
我们来看下ReentrantLock的调用过程
经过源码分析，我们看到ReentrantLock把所有的Lock都委托给Sync类进行处理，该类继承自AQS，其类关系图如下
其中Sync又有两个final static的子类NonfairSync和FairSync用于支持非公平锁和公平锁。我们先来挑一个看下对应Reentrant.lock()的调用过程（默认为非公平锁）
这些模版很难让我们直观的看到整个调用过程，但是通过上面的过程图和AbstractQueuedSynchronizer的注释可以看出，AbstractQueuedSynchronizer抽象了大多数Lock的功能，而只把tryAcquire(int)委托给子类进行多态实现。tryAcquire用于判断对应线程事都能够获取锁，无论成功与否，AbstractQueuedSynchronizer都将处理后面的流程。
简单来讲，AQS会把所有请求锁的线程组成一个CLH的队列，当一个线程执行完毕释放锁(Lock.unlock())的时候，AQS会激活其后继节点，正在执行的线程不在队列当中，而那些等待的线程全部处于阻塞状态，经过源码分析，我们可以清楚的看到最终是通过LockSupport.park()实现的，而底层是调用sun.misc.Unsafe.park()本地方法，再进一步，HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。其运行示意图如下
与synchronized相同的是，这个也是一个虚拟队列，并不存在真正的队列示例，仅存在节点之前的前后关系。（注：原生的CLH队列用于自旋锁，JUC将其改造为阻塞锁）。和synchronized还有一点相同的是，就是当获取锁失败的时候，不是立即进行阻塞，而是先自旋一段时间看是否能获取锁，这对那些已经在阻塞队列里面的线程显然不公平（非公平锁的实现，公平锁通过有序队列强制线程顺序进行），但会极大的提升吞吐量。如果自旋还是获取失败了，则创建一个节点加入队列尾部，加入方法仍采用CAS操作，并发对队尾CAS操作有可能会发生失败，AQS是采用自旋循环的方法，知道CAS成功！下面我们来看下锁的实现细节！
锁的实现依赖与lock()方法，Lock()方法首先是调用acquire(int)方法，不管是公平锁还是非公平锁
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}Acquire()方法默认首先调用tryAcquire(int)方法，而此时公平锁和不公平锁的实现就不一样了。
1、Sync.NonfairSync.TryAcquire（非公平锁）
nonfairTryAcquire方法是lock方法间接调用的第一个方法，每次调用都会首先调用这个方法，我们来看下对应的实现代码：
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
该方法首先会判断当前线程的状态，如果c==0 说明没有线程正在竞争锁。（反过来，如果c!=0则说明已经有其他线程已经拥有了锁）。如果c==0，则通过CAS将状态设置为acquires(独占锁的acquires为1)，后续每次重入该锁都会+1，每次unlock都会-1，当数据为0时则释放锁资源。其中精妙的部分在于：并发访问时，有可能多个线程同时检测到c为0，此时执行compareAndSetState(0, acquires))设置，可以预见，如果当前线程CAS成功，则其他线程都不会再成功，也就默认当前线程获取了锁，直接作为running线程，很显然这个线程并没有进入等待队列。如果c!=0，首先判断获取锁的线程是不是当前线程，如果是当前线程，则表明为锁重入，继续+1，修改state的状态，此时并没有锁竞争，也非CAS，因此这段代码也非常漂亮的实现了偏向锁。
Lock的底层怎么实现的？源码怎么写的？
ock的实现完全是由java写的，和操作系统或者是JVM虚拟机没有任何关系
sychronized的底层实现？
。我们先通过反编译下面的代码来看看Synchronized是如何实现对代码块进行同步的：synchronized和jvm平台相关，会调用平台硬件指令加锁，解锁，
1 package com.paddx.test.concurrent;
2
3 public class SynchronizedDemo {
4 public void method() {
5 synchronized (this) {
6 System.out.println("Method 1 start");
7 }
8 }
9 }
反编译结果：
关于这两条指令的作用，我们直接参考JVM规范中描述：
monitorenter ：
Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:
• If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor.
• If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count.
• If another thread already owns the monitor associated with objectref, the thread blocks until the monitor's entry count is zero, then tries again to gain ownership.
这段话的大概意思为：
每个对象有一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：
1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1.
3.如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权。
monitorexit：
The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref.
The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.
这段话的大概意思为：
执行monitorexit的线程必须是objectref所对应的monitor的所有者。
指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。
通过这两段描述，我们应该能很清楚的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。
我们再来看一下同步方法的反编译结果：
源代码：
1 package com.paddx.test.concurrent;
2
3 public class SynchronizedMethod {
4 public synchronized void method() {
5 System.out.println("Hello World!");
6 }
7 }
反编译结果：
从反编译的结果来看，方法的同步并没有通过指令monitorenter和monitorexit来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了ACC_SYNCHRONIZED标示符。JVM就是根据该标示符来实现方法的同步的：当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。 其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。
sychronized修饰静态方法和修饰普通方法有什么区别？
修饰静态方法，同步监视器是这个类的class实例，修饰普通方法，同步监视器是这个类的实例。
在static方法前加synchronizedstatic：静态方法属于类方法，它属于这个类，获取到的锁，是属于类的锁。
在普通方法前加synchronizedstatic：非static方法获取到的锁，是属于当前对象的锁。
多线程有哪些常见的线程安全的类？
喂（Vector）
S（Stack）
H（hashtable）
E（enumeration）