java基础面试题（real）

接口都是抽象方法

1.HashMap的工作原理是什么？

此地方可以不说： 设置初始容量与加载因子要讲求相对平衡,如果加载因子过低,则rehash过于频繁,影响性能
* 如果初始容量设置太高或者加载因子设置太高,影响查询效率
当计算的位置,有数据时,会发生hash冲突/hash碰撞,解决的办法就是采用链表的结构,在数组中指定位置处已有元素之后插入新的元素,也就是说数组中的元素都是最早加入的节点

HashMap底层原理：
1. HashMap概述：
HashMap底层是一个Entry[ ]数组,当存放数据时,会根据hash算法来计算数据的存放位置
算法:hash(key)%n , n就是数组的长度,其实也就是集合的容量
如果数组该位置上没有元素，就直接将该元素放到此数组中的该位置上，
当计算的位置,有数据时,会发生hash冲突/hash碰撞,解决的办法就是采用链表的结构,那么在这个位置上的元素将以链表的形式存放，新加入的放在链头，最先加入的放在链尾。

其次就是hashmap底层是（k,v）并允许使用null值和null键。Map存放的都是无序的数据，Map可以根据键来提取对应的值，Map的键不允许重复,如果重复,对应的值会被覆盖，但是map的value值可以重复；

Map的初始容量是16,默认的加载因子是0.752. 就会扩容2倍，HashMap的数据结构：    
2.HashMap采用数组+链表+红黑树实现。
数组+链表+红黑树的存储方式，当链表长度超过8时，将链表转换为红黑树。在性能上进一步得到提升

2.HashMap中的“死锁”是怎么回事？

说一说HashMap中“死锁”是怎么回事
HashMap是非线程安全，死锁一般都是产生于并发情况下。我们假设有二个进程T1、T2，HashMap容量为2,T1线程放入key A、B、C、D、E。在T1线程中A、B、C Hash值相同，于是形成一个链接，假设为A->C->B，而D、E Hash值不同，于是容量不足，需要新建一个更大尺寸的hash表，然后把数据从老的Hash表中 迁移到新的Hash表中(refresh)。这时T2进程闯进来了，T1暂时挂起，T2进程也准备放入新的key，这时也 发现容量不足，也refresh（刷新）一把。refresh（刷新）之后原来的链表结构假设为C->A，之后T1进程继续执行，链接结构 为A->C,这时就形成A.next=B,B.next=A的环形链表。一旦取值进入这个环形链表就会陷入死循环。

下面地方可以不说：
替代方案
使用ConcurrentHashMap进行替代，ConcurrentHashMap是一个线程安全的Hash Table。 可能有人会使用HashTable。当然HashTable也是线程安全,但HashTable锁定的是整个Hash表，效率相对比较低。而ConcurrentHashMap可以做到读取数据不加锁，并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小。# HashMap中能put两个相同key吗？为什么？
不可以，如果不重写有两个相同的key那么一个key就会被另一个key覆盖掉
但可以put两个重复的value值

3.HashMap中相同的多个key能否put多个value，相同的Key下存储了多个值

相同的Key下能否存储多个值
可以：有两个关键的方法：key的hashCode（）和map的put（）方法，前一个用于比较key是否相同，后一个用于插入方式的实现。只要重写了key的hashCode（）和map的put（）方法，应该就可以实现对于相同key下多个value的存储。	问题的答案
具体做法是：由于判断key是否存在的时候是先比较key的hashCode，再比较相等或equals的，所以重写hashCode()和equals()方法即可实现添加重复元素。重写这两个方法之后就可以覆盖重复的键值对，如果需要对value进行叠加，调用put()方法之前用containsKey()方法判断是否有重复的键值，如果有，则用get()方法获取原有的value，再加上新加入的value即可。	底层的实现原理

4.HashMap中的键值可以为null吗？原理？

hashmap键值可以为null，hashMap中允许存在key为null的值,只不过只能有一个，后续出现的key为null的值会覆盖前一个;

1、通过HashMap的put方法可以向变量中添加值。put方法有两个参数，就是要添加的数据的键和值。
2、通过HashMap的get方法可以向变量中取值。get方法需要传入一个参数，那个参数是键值，在HashMap中，键值是唯一的。

HashMap扩容机制？

扩容机制
扩容时机：
1）当链表长度大于8的时候并且数组的长度小于64时优先进行扩容
2） 当元素个数大于阈值时，进行扩容。
怎么扩容：
调用resize（）方法，
1.首先进行异常情况的判断，如 ：是否需要初始化，二是：若当前容量>最大值则不扩容，
2.然后根据新容量（是就容量的2倍、）新建数组，将旧数组上的数据（键值对）转移到新的数组中，这里包括：（遍历旧数组的每个元素，重新计算每个数据在数组中的存放位置。（原位置或者原位置+旧容量），将旧数组上的每个数据逐个转移到新数组中，这里采用的是尾插法。）
3.新数组table引用到HashMap的table属性上
4.最后重新设置扩容阙值，此时哈希表table=扩容后（2倍）&转移了旧数据的新table

ConcurrentHashMap的底层原理
ConcurrentHashMap的JDK8已经摒弃了Segment段锁的概念，由于在于JDK8的锁粒度更细，理想情况下talbe数组元素的大小就是其支持并发的最大个数，数据结构采用volatile修饰的table数组＋单向链表＋红黑树的结构，并发控制使用Synchronized和CAS来操作，整个看起来就像是优化过且线程安全的HashMap。

5.如何确定元素存放数组的位置

HashMap底层是一个Entry[ ]数组,当存放数据时,会根据hash算法来计算数据的存放位置
算法:hash(key)%n , n就是数组的长度,其实也就是集合的容量

6.map.put(k,v)实现原理

第一步首先将k,v封装到Node对象当中（节点）。第二步它的底层会调用K的hashCode()方法得出hash值。第三步通过哈希表函数/哈希算法，将hash值转换成数组的下标，下标位置上如果没有任何元素，就把Node添加到这个位置上。如果说下标对应的位置上有链表。此时，就会拿着k和链表上每个节点的k进行equal。如果所有的equals方法返回都是false，那么这个新的节点将被添加到链表的末尾。如其中有一个equals返回了true，那么这个节点的value将会被覆盖。

7.map.get(k)实现原理

第一步：先调用k的hashCode()方法得出哈希值，并通过哈希算法转换成数组的下标。第二步：通过上一步哈希算法转换成数组的下标之后，在通过数组下标快速定位到某个位置上。重点理解如果这个位置上什么都没有，则返回null。如果这个位置上有单向链表，那么它就会拿着参数K和单向链表上的每一个节点的K进行equals，如果所有equals方法都返回false，则get方法返回null。如果其中一个节点的K和参数K进行equals返回true，那么此时该节点的value就是我们要找的value了，get方法最终返回这个要找的value。

8.为何随机增删、查询效率都很高的原因是？

原因：
数组
优点：是随机读取效率很高，原因数组是连续（随机访问性强，查找速度快）。
缺点：插入和删除数据效率低，因插入数据，这个位置后面的数据在内存中要往后移的，且大小固定不易动态扩展。

链表特点

区间离散，占用内存宽松，空间复杂度小，时间复杂度O(N)。
优点：插入删除速度快，内存利用率高，没有大小固定，扩展灵活。
缺点：不能随机查找，每次都是从第一个开始遍历（查询效率低）。

哈希表特点

哈希表也叫散列表，是一种神奇的结构，最大的特点就是快。它的结构有很多种，最流行、最容易理解的是：顺序表+链表的结构。主结构是长度可以动态变化的顺序表，每个顺序表的节点可以单独引出一个链表。哈希表的原理可以从以下三点阐述。

添加数据原理：

1）、计算哈希码，调用hashCode()方法，结果是一个int值，整数的哈希码取自身即可

2）、根据哈希码计算存储位置（数组的索引）【y = k(x) （除留取余法）存入哈希表】

3）、将数据存入指定位置，如果已经有元素存在，就是出现了冲突，需要沿着链表比较，有重复的元素，不存储。没有，就存储。

结论：添加快。时间复杂度O(1)；无序。

查询数据的原理：

和添加过程一样，还是三步搞定。结论：查询快。

总结：哈希表的神奇之处在于按照内容查询，理想情况下可以达到数组索引查询的时间复杂度O(1)。核心在于其查询不是基于比较的，而是基于计算的。当存在冲突时，会降低效率。

如何减少冲突：

1）装填因子：哈希表的长度和表中的记录数的比例。超过装填因子就要扩容。不然冲突的概率会大大提高，从而影响性能。

2）哈希函数的选择

直接定址法 平方取中发 折叠法 除留取余法等

3）处理冲突的方法

链地址法 开放地址法 再散列法 建立一个公共溢出区

hashCode和equals()在哈希表添加查询中的作用：

1）hashCode()：计算哈希码，是一个整数，根据哈希码可以计算出数据在哈希表中的存储位置。

2）equals()：添加时出现了冲突，需要通过equals进行比较，判断是否相同，查询时也需要使用equals进行比较，判断是否相同。

9.为什么放在hashMap集合key部分的元素需要重写equals方法？

hashCode()用来判定二者的hash值是否相同,重写后根据属性生成
equlas()用来判断属性的值是否相同,重写后,根据属性判断
–equlas()判断数据如果相等,hashCode()必须相同
–equlas()判断数据如果不等,hashCode()尽量不同

10.HashMap总结

无序，不可重复为什么是无序的？因为不一定挂到哪一个单向链表上的，因此加入顺序和取出顺序也不一样。怎么保持不可重复？使用equals方法来保证HashMap集合key不可重复，如key重复来，value就会覆盖。存放在HashMap集合key部分的元素，其实就是存放在HashSet集合中，则HashSet集合也需要重写equals和hashCode方法。hashmap集合的默认初始化容量为16，默认加载因子为0.75，也就是说这个默认加载因子是当hashMap集合底层数组的容量达到75%时，数组就开始扩容。hashmap集合初始化容量是2的陪数，为了达到散列均匀，提高hashmap集合的存取效率，

hashset的原理

HashSet插入

HashSet : 底层是哈希表，包装了HashMap，，当有新值加入时，底层的HashMap会判断Key值是否存在（HashMap细节请移步深入理解HashMap），如果不存在，则插入新值，同时这个插入的细节会依照HashMap插入细节；如果存在就不插入，当然K仍然不许重复。

set集合的特点

Set集合中的数据是无序的(因为Set集合没有下标)
Set集合中的元素不可以重复 – 常用来给数据去重
HashSet : 底层是哈希表，包装了HashMap，相当于向HashSet中存入数据时，会把数据作为K，存入内部的HashMap中。当然K仍然不许重复。
TreeSet : 底层是TreeMap,也是红黑树的形式,便于查找数据

11.Java中常见的集合有哪些

12.Map接口和Collection接口是所有集合框架的父接口

Collection接口的子接口包括：Set接口和List接口。Set中不能包含重复的元素。List是一个有序的集合，可以包含重复的元素，提供了按索引访问的方式。
Map接口的实现类主要有：HashMap、Hashtable、ConcurrentHashMap以及TreeMap等。Map不能包含重复的key，但是可以包含相同的value。根据键得到值，对map集合遍历时先得到键的set集合，对set集合进行遍历，得到相应的值。
Set接口的实现类主要有：HashSet、TreeSet、LinkedHashSet等
List接口的实现类主要有：ArrayList、LinkedList、Stack以及Vector等
Iterator，所有的集合类，都实现了Iterator接口，这是一个用于遍历集合中元素的接口，主要包含以下三种方法：
hasNext()是否还有下一个元素
next()返回下一个元素
remove()删除当前元素

13.collection

collection是一个集合
集合类与数组最主要的不同之处是,数组的长度是固定的,集合的长度是可变的，,插入/删除等操作集合的访问方式比较灵活
数组一旦创建长度不可改变，所以数组的缩容（删除元素），和数组的扩容（增加元素）并不是直接改变原数组，而是创建一个新长度的数组

集合的继承结构

Collection接口
List 接口【数据有下标，有序，可重复】
ArrayList子类
LinkedList子类
Set 接口【数据无下标，无序，不可重复】
HashSet子类
Map 接口【键值对的方式寸数据】
HashMap子类

List方法速查表

ArrayList

内部是用数组结构存放数据、封装数组的操作,每个对象都有下标
内部数组默认的初始容量是10,如果不够会以1.5倍的容量增长
查询快,增删数据效率会低
List 接口【数据有下标，有序，可重复】

14.线程和进程

进程就是正在运行的程序,它代表了程序所占用的内存区域

进程的特点

独立性
进程是系统中独立存在的实体,它可以拥有自己独立的资源,每个进程都拥有自己私有的地址空间,在没有经过进程本身允许的情况下,一个用户进程不可以直接访问其他进程的地址空间
动态性
进程与程序的区别在于,程序只是一个静态的指令集合,而进程是一个正在系统中活动的指令集合,程序加入了时间的概念以后,称为进程,具有自己的生命周期和各种不同的状态,这些概念都是程序所不具备的.
并发性
多个进程可以在单个处理器CPU上，多个进程之间不会互相影响.

并发和并行

高可用:指在高并发的情景中,尽可能的保证程序的可用性,减少系统不能提供服务的时间

线程

进程与线程的关系

一个操作系统中可以有多个进程,一个进程中可以包含一个线程(单线程程序),也可以包含多个线程(多线程程序)
每个线程在共享同一个进程中的内存的同时,又有自己独立的内存空间.

多线程的特性

随机性

线程的随机性指的是同一时刻,只有一个程序在执行，我们表面上看起来是多个程序同时运行，只不过是切换的时间是纳秒级别的；

CPU分时调度

时间片,即该线程被允许运行的时间，如果在时间片用完时线程还在执行,也就是当前线程没有结束，那么，CPU将被剥夺当前线程并分配给另一个线程,并将当前线程挂起,如果线程在时间片用完之前阻塞或结束,则CPU当即进行切换,从而避免CPU资源浪费,当再次切换到之前挂起的线程,恢复现场,继续执行。
注意:我们无法控制OS选择执行哪些线程,OS底层有自己规则,如:

线程的状态

执行:为就绪线程分配CPU即可变为执行状态"
就绪:正在执行的线程由于时间片用完被剥夺CPU暂停执行,就变为就绪状态
阻塞:由于发生某事件,使正在执行的线程受阻,无法执行,则由执行变为阻塞
(例如线程正在访问临界资源,而资源正在被其他线程访问)
反之,如果获得了之前需要的资源,则由阻塞变为就绪状态,等待分配CPU再次执行

创建状态:线程的创建比较复杂,需要先申请PCB,然后为该线程运行分配必须的资源,并将该线程转为就绪状态插入到就绪队列中
终止状态:等待OS进行善后处理,最后将PCB清零,并将PCB返回给系统

线程生命周期,主要有五种状态:

新建状态(New) : 当线程对象创建后就进入了新建状态.如:Thread t = new MyThread();
就绪状态(Runnable):当调用线程对象的start()方法,线程即为进入就绪状态.
处于就绪(可运行)状态的线程,只是说明线程已经做好准备,随时等待CPU调度执行,并不是执行了t.start()此线程立即就会执行
运行状态(Running):当CPU调度了处于就绪状态的线程时,此线程才是真正的执行,即进入到运行状态
就绪状态是进入运行状态的唯一入口,也就是线程想要进入运行状态状态执行,先得处于就绪状态
阻塞状态(Blocked):处于运状态中的线程由于某种原因,暂时放弃对CPU的使用权,停止执行,此时进入阻塞状态,直到其进入就绪状态才有机会被CPU选中再次执行.
根据阻塞状态产生的原因不同,阻塞状态又可以细分成三种:
等待阻塞:运行状态中的线程执行wait()方法,本线程进入到等待阻塞状态
同步阻塞:线程在获取synchronized同步锁失败(因为锁被其他线程占用),它会进入同步阻塞状态
其他阻塞:调用线程的sleep()或者join()或发出了I/O请求时,线程会进入到阻塞状态.当sleep()状态超时.join()等待线程终止或者超时或者I/O处理完毕时线程重新转入就绪状态
死亡状态(Dead):线程执行完了或者因异常退出了run()方法,该线程结束生命周期

创建线程 的方式有哪些

通过实现Runnable接口来创建Thread线程：

步骤1：创建实现Runnable接口的类：

4 多线程代码创建方式1:继承Thread

4.1 概述
Thread类本质上是实现了Runnable接口的一个实例,代表一个线程的实例
启动线程的唯一方法就是通过Thread类的start()实例方法
start()方法是一native方法,它将通知底层操作系统,.最终由操作系统启动一个新线程,操作系统将执行run()
这种方式实现的多线程很简单,通过自己的类直接extends Thread,并重写run()方法,就可以自动启动新线程并执行自己定义的run()方法
模拟开启多个线程,每个线程调用run()方法.

多线程代码创建方式2:实现Runnable接口

5.1 概述

如果自己的类已经extends另一个类,就无法多继承,此时,可以实现一个Runnable接口

5.2 常用方法
void run()使用实现接口Runnable的对象创建线程时,启动该线程将导致在独立执行的线程中调用对象的run()方法

两种方式的优缺点

继承Thread类：启动线程的唯一方法就是通过Thread类的start()实例方法
优点: 编写简单,如果需要访问当前线程,无需使用Thread.currentThread()方法,直接使用this即可获得当前线程
缺点: 自定义的线程类已继承了Thread类,所以后续无法再继承其他的类

实现Runnable接口：void run()使用实现接口Runnable的对象创建线程时,
优点: 自定义的线程类只是实现了Runnable接口或Callable接口,后续还可以继承其他类,在这种方式下,多个线程可以共享同一个target对象,所以非常适合多个相同线程来处理同一份资源的情况,从而可以将CPU、代码、还有数据分开(解耦),较好地体现了面向对象的思想
缺点: 编程稍微复杂,如想访问当前线程,则需使用Thread.currentThread()方法

我更喜欢实现Runnable接口这种方法，当然这也是现在大多程序员会选用的方法。因为一个类只能继承一个父类而可以实现多个接口。同时，线程池也是非常高效的，很容易实现和使用。

15.sleep和wait的方法

对于sleep()方法，我们首先要知道该方法是属于Thread类中的。而wait()方法，则是属于Object类中的。
sleep()方法导致了程序暂停执行指定的时间，让出cpu该其他线程，但是他的监控状态依然保持者，当指定的时间到了又会自动恢复运行状态。
在调用sleep()方法的过程中，线程不会释放对象锁。
而当调用wait()方法的时候，线程会放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象调用notify()方法后本线程才进入对象锁定池准备
获取对象锁进入运行状态。

第三种解释：

这两者的施加者是有本质区别的.
sleep()是让某个线程暂停运行一段时间,其控制范围是由当前线程决定,也就是说,在线程里面决定.好比如说,我要做的事情是 “点火->烧水->煮面”,而当我点完火之后我不立即烧水,我要休息一段时间再烧.对于运行的主动权是由我的流程来控制.

这里的sleep()方法,其控制范围是由当前线程决定,  好比如说,我要做的事情是 "点火->烧水->煮面",而当我点完火之后我不立即烧水,我要休息一段时间再烧.对于运行的主动权是由我的流程来控制.

而wait(),首先,这是由某个确定的对象来调用的,将这个对象理解成一个传话的人,当这个人在某个线程里面说"暂停!“,也是 thisOBJ.wait(),这里的暂停是阻塞,还是"点火->烧水->煮饭”,thisOBJ就好比一个监督我的人站在我旁边,本来该线 程应该执行1后执行2,再执行3,而在2处被那个对象喊暂停,那么我就会一直等在这里而不执行3,但正个流程并没有结束,我一直想去煮饭,但还没被允许, 直到那个对象在某个地方说"通知暂停的线程启动!",也就是thisOBJ.notify()的时候,那么我就可以煮饭了,这个被暂停的线程就会从暂停处 继续执行.

而wait(),首先,这是由某个确定的对象来调用的,将这个对象理解成一个传话的人,当这个人在某个线程里面说"暂停!",也是调用了wait(),这里的暂停是阻塞,还是"点火->烧水->煮饭",一个监督我的人站在我旁边,本来该线 程应该执行1后执行2,再执行3,如果在2处被那个对象喊暂停,那么我就会一直等在这里而不执行3,但正个流程并没有结束,我一直想去煮饭,但还没被允许, 直到人说"暂停的线程启动!",调用notify()的时候,那么我就可以煮饭了,这个被暂停的线程就会从暂停处 继续执行.

其实两者都可以让线程暂停一段时间,但是本质的区别是一个线程的运行状态控制,一个是线程之间的通讯的问题

在java.lang.Thread类中，提供了sleep()，
而java.lang.Object类中提供了wait()， notify()和notifyAll()方法来操作线程
sleep()可以将一个线程睡眠，参数可以指定一个时间。
而wait()可以将一个线程挂起，直到超时或者该线程被唤醒。
wait有两种形式wait()和wait(milliseconds).
sleep和wait的区别有：
1，这两个方法来自不同的类分别是Thread和Object
2，最主要是sleep方法没有释放锁，而wait方法释放了锁，使得其他线程可以使用同步控制块或者方法。

volatile关键字 的原理

volatile原理：

被volatile关键字修饰的变量，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量上的操作与其他内存操作一起重排序。volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在读取volatile类型的变量时总会返回最新写入的值。
volatile在Java并发编程中常用于保持内存可见性和防止指令重排序。内存可见性（Memory Visibility）：所有线程都能看到共享内存的最新状态；防止指令重排：在基于偏序关系的Happens-Before内存模型中，指令重排技术大大提高了程序执行效率，但同时也引入了一些问题

数据库的乐观素和悲观锁

悲观锁

当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，最好的办法就是直接对该数据进行加锁以防止并发。

这种借助数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（缩写“PCC”）。

之所以叫做悲观锁，是因为这是一种对数据的修改抱有悲观态度的并发控制方式。我们一般认为数据被并发修改的概率比较大，所以需要在修改之前先加锁。

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。


但是在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；

另外，还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

乐观锁

乐观锁（ Optimistic Locking ） 是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

悲观锁实现方式

悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：

在对记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
**如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。**具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他事务对该记录做加锁的操作，都要等待当前事务解锁或直接抛出异常。
我们拿比较常用的MySql Innodb引擎举例，来说明一下在SQL中如何使用悲观锁。

注意：要使用悲观锁，我们必须关闭mysql数据库中自动提交的属性，命令set autocommit=0;即可关闭，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
我们举一个简单的例子，如淘宝下单过程中扣减库存的需求说明一下如何使用悲观锁：

//0.开始事务
begin; 
//1.查询出商品库存信息
select quantity from items where id=1 for update;
//2.修改商品库存为2
update items set quantity=2 where id = 1;
//3.提交事务
commit;

以上，在对id = 1的记录修改前，先通过for update的方式进行加锁，然后再进行修改。这就是比较典型的悲观锁策略。

如果以上修改库存的代码发生并发，同一时间只有一个线程可以开启事务并获得id=1的锁，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，这点需要注意。

乐观锁实现方式

使用乐观锁就不需要借助数据库的锁机制了。

乐观锁的概念中其实已经阐述了他的具体实现细节：主要就是两个步骤：冲突检测和数据更新。其实现方式有一种比较典型的就是Compare and Swap(CAS)技术。

CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

比如前面的扣减库存问题，通过乐观锁可以实现如下：

/查询出商品库存信息，quantity = 3
select quantity from items where id=1
//修改商品库存为2
update items set quantity=2 where id=1 and quantity = 3;

以上，我们在更新之前，先查询一下库存表中当前库存数（quantity），然后在做update的时候，以库存数作为一个修改条件。当我们提交更新的时候，判断数据库表对应记录的当前库存数与第一次取出来的库存数进行比对，如果数据库表当前库存数与第一次取出来的库存数相等，则予以更新，否则认为是过期数据。

但是以上更新语句存在一个比较重要的问题，即ABA问题。

比如说一个线程1从数据库中取出库存数3，这时候另一个线程2也从数据库中库存数3，并且线程2进行了一些操作将库存数变成了2，紧接着又将库存数变成3，这时候线程1进行CAS操作发现数据库中仍然是3，然后线程1操作成功。尽管线程1的CAS操作成功，但是不代表这个过程就是没有问题的。

有一个比较好的办法可以解决ABA问题，那就是通过一个单独的可以顺序递增的version字段。改为以下方式即可

//查询出商品信息，version = 1
select version from items where id=1
//修改商品库存为2
update items set quantity=2,version = 3 where id=1 and version = 2;

乐观锁每次在执行数据的修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行+1操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现ABA问题，因为版本号只会增加不会减少。

除了version以外，还可以使用时间戳，因为时间戳天然具有顺序递增性。

以上SQL其实还是有一定的问题的，就是一旦高并发的时候，就只有一个线程可以修改成功，那么就会存在大量的失败。

对于像淘宝这样的电商网站，高并发是常有的事，总让用户感知到失败显然是不合理的。所以，还是要想办法减小乐观锁的粒度的。

有一条比较好的建议，可以减小乐观锁力度，最大程度的提升吞吐率，提高并发能力！如下：

//修改商品库存
update item 
set quantity=quantity - 1 
where id = 1 and quantity - 1 > 0

以上SQL语句中，如果用户下单数为1，则通过quantity - 1 > 0的方式进行乐观锁控制。

以上update语句，在执行过程中，会在一次原子操作中自己查询一遍quantity的值，并将其扣减掉1。

高并发环境下锁粒度把控是一门重要的学问，选择一个好的锁，在保证数据安全的情况下，可以大大提升吞吐率，进而提升性能。

如何选择

在乐观锁与悲观锁的选择上面，主要看下两者的区别以及适用场景就可以了。

1、乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
2、悲观锁依赖数据库锁，效率低。更新失败的概率比较低。

随着互联网三高架构（高并发、高性能、高可用）的提出，悲观锁已经越来越少的被使用到生产环境中了，尤其是并发量比较大的业务场景。

乐观锁和悲观锁说明

悲观锁

当我们要对一个数据库中的一条数据进行修改的时候，为了避免同时被其他人修改，我们通过加锁方式以防止并发。
这种数据库锁机制在修改数据之前先锁定，再修改的方式被称之为悲观并发控制（缩写“PCC”）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他事务对该记录做加锁的操作，都要等待当前事务解锁或直接抛出异常。

并且在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会；
另外，还会降低并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数据。

乐观锁

乐观锁（ Optimistic Locking ） 是相对悲观锁而言的，乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

乐观锁主要就是两个功能：冲突检测和数据更新。

如何选择
1、乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
2、悲观锁依赖数据库锁，效率低。更新失败的概率比较低。

垃圾回收机制

在Java中程序员是不需要去释放一些对象的内存而是有虚拟机自行执行，在Java中有一个垃圾回收线程它是优先级的，在正常情况下是不会执行的只有在虚拟机空闲或堆内存不足的时候才会触发执行扫描哪些没有被任何引用的对象并将他们添加到会输集合中进行回收；
总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否会被这些根集对象引用，不能够被引用的对象就会被垃圾收集器回收。

三、垃圾检测、回收算法

垃圾收集器一般必须完成两件事：检测出垃圾；回收垃圾。怎么检测出垃圾？一般有以下几种方法：

引用计数法：给一个对象添加引用计数器，每当有个地方引用它，计数器就加1；引用失效就减1。

好了，问题来了，如果我有两个对象A和B，互相引用，除此之外，没有其他任何对象引用它们，实际上这两个对象已经无法访问，即是我们说的垃圾对象。但是互相引用，计数不为0，导致无法回收，所以还有另一种方法：

可达性分析算法：以根集对象为起始点进行搜索，如果有对象不可达的话，即是垃圾对象。这里的根集一般包括java栈中引用的对象、方法区常良池中引用的对象

本地方法中引用的对象等。

总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否会被这些根集对象引用，不能够被引用的对象就会被垃圾收集器回收。一般回收算法也有如下几种：

1.标记-清除（Mark-sweep）

算法和名字一样，分为两个阶段：标记和清除。标记所有需要回收的对象，然后统一回收。这是最基础的算法，后续的收集算法都是基于这个算法扩展的。

不足：效率低；标记清除之后会产生大量碎片。效果图如下：