【实用的微缩版初级开发面试题】

jvm运行数据区如何划分

1.线程私有内存：程序计数器、虚拟机栈、本地方法栈
2. 线程共享内存：Java堆、方法区、运行时常量池

堆和栈的区别

栈：栈是系统自动分配，获得的空间较小，速度较快，底层是连续空间
堆：是人为申请开辟，获得的空间较大，速度较慢，底层是不连续空间

线程与进程

线程：是处理器（cpu）调度的独立单位
进程：是资源分布的基本单位
做个简单的比喻：进程=火车，线程=车厢
1、线程在进程下行进（单纯的车厢无法运行）
2、一个进程可以包含多个线程（一辆火车可以有多个车厢）
3、不同进程间数据很难共享（一辆火车上的乘客很难换到另外一辆火车，比如站点换乘）
4、同一进程下不同线程间数据很易共享（A车厢换到B车厢很容易）
5、进程要比线程消耗更多的计算机资源（采用多列火车相比多个车厢更耗资源）
6、进程间不会相互影响，一个线程挂掉将导致整个进程挂掉（一列火车不会影响到另外一列火车，但是如果一列火车上中间的一节车厢着火了，将影响到所有车厢）

MyBatis持久层框架三个主要特点

①、提供映射标签：支持对象与数据库ORM字段关系映射；
②、提供xml标签，支持编写动态sql；
③、减少JDBC的代码；

（详情如下：）

MyBatis框架概念

（1）mybatis是一个持久层框架，它内部封装了jdbc，不需要花费精力去处理加载驱动、创建连接等过程，
消除了JDBC大量冗余的代码。
（2）mybatis通过xml或注解的方式将要执行的各种statement配置起来，并通过java对象和statement中
sql的动态参数进行映射生成最终执行的sql语句，最后由mybatis框架执行sql并将结果映射为java对象并返回。
（3）MyBatis 支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设
置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJO映射成数据库中的记录。
（4）提供了很多第三方插件（分页插件 / 逆向工程）；
（5）能够与Spring很好的集成；
（6）MyBatis相当灵活，SQL写在XML里，从程序代码中彻底分离，解除sql与程序代码的耦合，便于统一管理，支持编写动态SQL语句。
（7） 提供映射标签，支持对象与数据库的ORM字段关系映射。
（8）SQL语句依赖于数据库，导致数据库移植性差，不能随意更换数据库。

Mybatis中#和$的区别？

#相当于对数据加上双引号，$相当于直接显示数据
#方式能够很大程度防止sql注入。
$方式无法防止Sql注入
$方式一般用于传入数据库对象
一般能用#的就别用$

HashMap

HashMap底层实现

向HashMap中添加一个元素时，当前元素的key会调用hashCode方法来决定它在数组中存放的位置。如果这个位置没有其他元素，会把这个键值对直接放到一个node类型的数组中，这个数组就是hashmap底层基础的数据结构。如果这个位置有其他元素，会继续拿着这个key调用equals方法和这个位置已存在的元素key进行对比，对比二个元素的key。key一样，返回true，原来的value值会被替换成新的value。key不一样，返回flase，这个位置就用链表的形式把多个元素串起来存放。

jdk1.7版本的HashMap数据结构就是数组加链表的形式存储元素的，但是会有弊端，当链表中的数据较多时，查询的效率会下降。所以JDK1.8版本做了一个升级，当链表长度大于8，并且数组长度大于64时，会转换为红黑树。因为红黑树需要进行左旋，右旋，变色操作来保持平衡，如果当数组长度小于64，使用数组加链表比使用红黑树查询速度要更快、效率更高。

在HashMap源码有这样一段描述，大致意思是说在理想状态下受随机分布的hashCode影响，链表中的节点遵循泊松分布，节点数是8的概率接近千分之一，这个时候链表的性能很差，所以在这种比较罕见和极端的情况下才会把链表转变为红黑树，大部分情况下HashMap还是使用链表，如果理想情况下，均匀分布，节点数不到8就已经自动扩容了。

1.7版本和1.8版本的差异

jdk1.7的hashmap有二个无法忽略的问题。

一个是扩容的时候需要rehash操作，将所有的数据重新计算HashCode，然后赋给新的HashMap，rehash的过程是非常耗费时间和空间的。
第二个是当并发执行扩容操作时会造成环形链和数据丢失的情况，开多个线程不断进行put操作，当旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，就是因为头插法，所以最后的结果打乱了插入的顺序，就有可能发生环形链和数据丢失的问题，引起死循环，导致CPU利用率接近100%。

在JDK1.8中，对HashMap这二点进行了优化。

第一点是经过rehash之后元素的位置，要么是在原位置，要么是原位置+原数组长度。不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了。在数组的长度扩大到原来的2倍， 4倍，8倍时，在resize(也就是length - 1)这部分，相当于在高位新增一个或多个1bit。

举个例子，hashmap默认的初始长度是16，负载因子是0.75，当元素被使用75%以上时，触发扩容操作，并且每次扩容一倍。扩容时：将旧数组中的元素转换后，填充到新数组中。通过底层获取索引indexfor方法里面有个（length -1）公式，取它的二进制，它的二进制位后八位是0000 1111，扩容二倍到32，通过公式（length -1）取31的二进制，它的后八位0001 1111，可以发现它的高位进的是1，然后和原来的hash码进行与操作，这样元素在数组中映射的位置要么不变，要不就是在原位置再移动2次幂的位置。

高位上新增的是1的话索引变成原位置+原数组长度，是0的话索引没变。这样既省去了重新计算hash值的时间，而且由于高位上新增的1bit是0还是1，可以认为是随机的，复杂度更高，从而让分布性更高些。
第二点，发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程环境下，会发生数据覆盖的情况。

举个例子，如果没有hash碰撞的时候，它会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，线程A会把线程B插入的数据给覆盖，导致数据发生覆盖的情况，发生线程不安全。

并发修改异常解决方案

HashMap在高并发场景下会出现并发修改异常，导致原因：并发争取修改导致，一个线程正在写，一个线程过来争抢，导致线程写的过程被其他线程打断，导致数据不一致。

第一种解决方案：使用HashTable：HashTable是线程安全的，只不过实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。
第二种解决方案：使用工具类Collections.synchronizedMap(new HashMap<>());和Hashtable一样，实现上在操作HashMap时自动添加了synchronized来实现线程同步，都对整个map进行同步，在性能以及安全性方面不如ConcurrentHashMap。
第三种解决方案：使用写时复制（CopyOnWrite）：往一个容器里面加元素的时候，不直接往当前容器添加，而是先将当前容器的元素复制出来放到一个新的容器中，然后新的元素添加元素，添加完之后，再将原来容器的引用指向新的容器，这样就可以对它进行并发的读，不需要加锁，因为当前容器不添加任何元素。利用了读写分离的思想，读和写是不同的容器。缺点也很明显，会有内存占用问题，在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存。会有数据一致性问题，CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。
第四种解决方案：使用ConcurrentHashMap：ConcurrentHashMap大量的利用了volatile，CAS等技术来减少锁竞争对于性能的影响。在JDK1.7版本中ConcurrentHashMap避免了对全局加锁，改成了局部加锁（分段锁），分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。不过这种结构的带来的副作用是Hash的过程要比普通的HashMap要长。所以在JDK1.8版本中CurrentHashMap内部中的value使用volatile修饰，保证并发的可见性以及禁止指令重排，只不过volatile不保证原子性，使用为了确保原子性，采用CAS（比较交换）这种乐观锁来解决。

hashmap优化

对hashmap使用的优化，有以下五点：

第一点，建议采用短String，Integer这样的类作为键。特别是String，他是不可变的，也是final的，而且已经重写了equals和hashCode方法，契合HashMap要求的计算hashCode的不可变性要求，核心思想就是保证键值的唯一性，不变性，其次是不可变性还有诸如线程安全的问题，这么定义键，可以最大限度的减少碰撞的出现。如果hashCode不冲突，那查找效率很高，但是如果hashCode一旦冲突，要调用equals一个字节一个自己的去比较，key越短效率越高。
第二点不使用for循环遍历map，而是使用迭代器遍历Map，使用迭代器遍历entrySet在各个数量级别效率都比较高。
第三点使用线程安全的ConcurrentHashMap来删除Map中的元素，或者在迭代器Iterator遍历时，使用迭代器iterator.remove()来删除元素。不可以for循环遍历删除，否则会产生并发修改异常CME。
第四点考虑加载因子地设定初始大小，设定时一定要考虑加载因子的存在，使用的时候最好估算存储的大小。可以使用Maps.newHashMapWithExpectedSize(预期大小)来创建一个HashMap，计算的过程guava会帮我们完成，Guava的做法是把默认容量的数字设置成预期大小 / 0.75F + 1.0F。
第五点减小加载因子，如果Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。
————————————————

MySQL知识点

四大特性

mysql的四大特性：原子性、一致性、隔离性、数据持久化。

隔离级别

mysql四大隔离级别：读未提交、读已提交、可重复读、可串行化。

一、 Read Uncommitted（读未提交）

在一个事务处理过程里读取了另一个未提交的事务中的数据。会导致脏读。

脏读(Drity Read)：

某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个回滚了操作，则后一个事务所读取的数据就会是不正确的。

举个例子，公司发工资了，领导把四万块钱打到我的账号上，但是该事务并未提交，而我正好去查看账户，发现工资已经到账，是四万，非常高兴。可是不幸的是，领导发现发给我的工资金额不对，是三万五元，于是迅速修改金额，将事务提交，最后我实际的工资只有三万五元，我就白高兴一场。

二、Read Committed（读已提交）

这是大多数数据库系统的默认隔离级别，但不是MySQL默认的。会导致不可重复读，事务a读取数据，事务b立马修改了这个数据并且提交事务给数据库，事务a再次读取这个数据就得到了不同的结果。

不可重复读(Non-repeatable read):

在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间更新了原有的数据。

举个例子，我拿着工资卡去消费，系统读取到卡里确实有一百块钱，这个时候我的女朋友刚好用我的工资卡在网上转账，把我工资卡的一百块钱转到另一账户，并在我之前提交了事务，当我扣款时，系统检查到我的工资卡已经没有钱，扣款失败，我会十分纳闷，明明卡里有钱的。

三、 Repeatable Read（可重读）

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。会导致幻读，InnoDB和Falcon存储引擎通过多版本并发控制机制解决了该问题。

幻读(Phantom Read):

在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

举个例子，当我拿着工资卡去消费时，一旦系统开始读取工资卡信息，这个时候事务开始，我的女朋友就不可能对该记录进行修改，也就是我的女朋友不能在这个时候转账。这就避免了不可重复读。假设我的女朋友在银行部门工作，她时常通过银行内部系统查看我的工资卡消费记录。有一天，她正在查询到我当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而我此时正好在外面胡吃海喝后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction … ），并提交了事务，随后我的女朋友把我当月工资卡消费的明细打印到A4纸上，却发现消费总额为1080元，我女朋友很诧异，以为出现了幻觉，幻读就这样产生了。

四、Serializable（可串行化）（更高级别隔离，避免脏读，避免不可重复读，避免幻读）

这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

垃圾回收器、垃圾回收算法、空间分配担保

垃圾回收器有：
新生代的三个垃圾回收器【serial，parnew，parallel scavenge】；
老年代【serial old，parallel old，cms】；
新生代和老年代都使用的垃圾回收器G1。

Serial

Serial是新生代下使用复制算法，单线程运行的垃圾回收器，简单高效，没有线程交互开销，专注于GC，这个垃圾回收器工作的时候会将所有应用线程全部冻结，而且是单核cpu，所以基本不会考虑使用它。

ParNew

ParNew是新生代下使用复制算法，多线程运行的垃圾回收器，可以并行并发GC，和serial对比，除了多核cpu并行gc其他基本相同。

Parallel scavenge

Parallel scavenge也是新生代下使用复制算法，可以进行吞吐量控制的多线程回收器，主要关注吞吐量，通过吞吐量的设置控制停顿时间，适应不同的场景。

复制算法

新生代中每次垃圾回收都要回收大部分对象，所以为了避免内存碎片化的缺陷，这个算法按内存容量将内存划分为大小相等的两块，每次只使用其中一块，当这一块存活区内存满后，将gc之后还存活的对象复制到另一块存活区上去，将已使用的内存清掉。

分代收集算法

按照分代收集算法的思想，把应用程序可用的堆空间分为年轻代，老年代，永久代，然后年轻代有被分为Eden区和二个Survivor存活区，比例分为8比1比1。当第一次eden区发生minor gc，会把存活的对象复制到其中的一个Survivor区，然后eden区继续放对象，直到触发gc，会把eden区和之前存放对象的Survivor区一起gc，二个区存活下来的对象，复制到另一个空的Survivor里面，这二个区就清空，然后将二个存活区角色互换。

进入老年代的几种情况

当对象在Survivor区躲过一次GC 后，年龄就会+1，存活的对象在二个Survivor区不停的移动，默认情况下年龄到达15的对象会被移到老年代中，这是对象进入到老年代的第一种情况。

这里就会有个问题，JVM分代年龄为什么是15次？
一个对象的GC年龄，是存储在对象头里面的，一个Java对象在JVM内存中的布局由三个部分组成，分别是对象头、实例数据、对齐填充。而对象头里面有4个bit位来存储GC年龄。

4个bit位能够存储的最大数值是15，所以从这个角度来说，JVM分代年龄之所以设置成15次是因为它最大能够存储的数值就是15。

虽然JVM提供了参数来设置分代年龄的大小，但是这个大小不能超过15。从设计角度来看，当一个对象触发了最大值15次gc，还没有办法被回收，就只能移动到old generation了。另外，设计者还引入了动态对象年龄判断的方式来决定把对象转移到old generation，也就是说不管这个对象的gc年龄是否达到了15次，只要满足动态年龄判断的依据，也同样会转移到old generation。

第二种情况就是，创建了一个很大的对象，这个对象的大小超过了jvm里面的一个参数max tenuring thread hold值，这个时候不会创建在eden区，新对象直接进入老年代。

第三种情况，如果在Survivor区里面，同一年龄的所有对象大小的总和大于Survivor区大小的一半，年龄大于等于这个年龄对象的，就可以直接进入老年代，举个例子，存活区只能容纳5个对象，有五个对象，1岁，2岁，2岁，2岁，3岁，3个2岁的对象占了存活区空间的5分之三，大于这个空间的一半了，这个时候大于等于2岁的对象，需要移动到老年代里面，也就是3个2岁的，一个3岁的对象移动到老年代里面。

Serial Old

Serial Old就是老年代下使用标记整理算法，单线程运行的垃圾回收器。

Parallel old

Parallel old也是老年代下使用标记整理算法，可以进行吞吐量控制的多线程回收器，在JDK1.6才开始提供，在JDK1.6之前，新生代使用ParallelScavenge 收集器只能搭配老年代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在老年代同样提供吞吐量优先的垃圾收集器而出现的。

上面的Serial Old，Parallel Old这二个垃圾回收器使用的是标记整理算法

标记整理算法

标记整理算法：标记后将存活对象移向内存的一端，清除端边界外的对象。标记整理算法可弥补，标记清除算法中内存碎片的缺点，也消除了复制算法当中，内存使用率只有90%的现象。
缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记整理算法要低于复制算法。

标记清除算法

标记清除算法分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。

CMS使用标记清除算法看中的就是它的效率高，只不过内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

CMS

CMS是老年代使用标记清除算法，并发收集低停顿的多线程垃圾回收器。CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：

初始标记，只是标记一下GC Roots，能直接关联的对象，速度很快，需暂停所有的工作线程。

重新标记，为了修正在并发标记期间，因用户程序继续运行，而导致标记产生变动的那部分对象的重新标记记录，需暂停所有的工作线程。

并发标记，进行GC Roots跟踪的过程，和用户线程一起工作，不需暂停工作线程。

并发清除，清除 GC Roots 不可达对象，和用户线程一起工作，不需暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。

CMS 收集器弊端：
1、无法处理浮动垃圾，已标记过的对象，进行并发清除时，会又有垃圾对象产生，此时浮动垃圾就没法清除了
2、它的算法特性，容易产生大量内存碎片。

G1

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，每个区域又可以根据分代理论分为eden区，Survivor区，只要这个区域里面出现了一个对象，超过了这个区域空间的一半就可以把它当作大对象，g1专门开辟了一块空间用来存储大对象，这个区域的大小，可以通过jvm的参数去设置，取值范围是1~32mb之间，那么如果有一个对象超过了32mb，那么jvm会分配二个连续的区域，用来存储这个大对象。

跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，保证了G1 收集器可以在有限时间获得最高的垃圾收集效率。
而且基于标记整理算法，不产生内存碎片。可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。在jdk1.9的时候，被设置成默认的垃圾回收器了

内存泄漏

内存泄漏：是指创建的对象已经没有用处，正常情况下应该会被垃圾收集器回收，但是由于该对象仍然被其他对象进行了无效引用，导致不能够被垃圾收集器及时清理，这种现象称之为内存泄漏。

内存堆积

内存泄漏会导致内存堆积，最终发生内存溢出，导致OOM。发生内存泄漏大部分是由于程序代码导致的，排查方法一般是使用 visualVM 进行heap dump，查看占用空间比较多的 class 对象，然后检查该对象的instances 以及 reference引用，最终定位到程序代码。如果堆内存比较大，进行head dump 产生的资源消耗不可接受，可以尝试使用轻量级的jmap生成堆转储快照分析，思路与使用可视化工具一样。

JVM调优

JVM调优情况十分复杂，各种情况都可能导致垃圾回收不能够达到预想的效果。对于场景问题，可以从如下几个大方向进行设计：

大访问压力下，MGC 频繁一些是正常的，只要MGC 延迟不导致停顿时间过长或者引发FGC ，那可以适当的增大Eden 空间大小，降低频繁程度，同时要保证，空间增大对垃圾回收产生的停顿时间增长是可以接受的。
如果MinorGC 频繁，且容易引发 Full GC。需要从如下几个角度进行分析。
a：每次MGC存活的对象的大小，是否能够全部移动到 S1区，如果S1 区大小 < MGC 存活的对象大小，这批对象会直接进入老年代。注意了，这批对象的年龄才1岁，很有可能再多等1次MGC 就能被回收了，可是却进入了老年代，只能等到Full GC 进行回收，很可怕。这种情况下，应该在系统压测的情况下，实时监控MGC存活的对象大小，并合理调整eden和s 区的大小以及比例。
b：还有一种情况会导致对象在未达到15岁之前，直接进入老年代，就是S1区的对象，相同年龄的对象所占总空间大小>s1区空间大小的一半，所以为了应对这种情况，对于S区的大小的调整就要考虑：尽量保证峰值状态下，S1区的对象所占空间能够在MGC的过程中，相同对象年龄所占空间不大于S1区空间的一半，因此对于S1空间大小的调整，也是十分重要的。
由于大对象创建频繁，导致Full GC 频繁。对于大对象，JVM专门有参数进行控制，-XX： PretenureSizeThreshold。超过这个参数值的对象，会直接进入老年代，只能等到full GC 进行回收，所以在系统压测过程中，要重点监测大对象的产生。如果能够优化对象大小，则进行代码层面的优化，优化如：根据业务需求看是否可以将该大对象设置为单例模式下的对象，或者该大对象是否可以进行拆分使用，或者如果大对象确定使用完成后，将该对象赋值为null，方便垃圾回收。
如果代码层面无法优化，则需要考虑：
a:调高-XX： PretenureSizeThreshold参数的大小，使对象有机会在eden区创建，有机会经历MGC以被回收。但是这个参数的调整要结合MGC过程中Eden区的大小是否能够承载，包括S1区的大小承载问题。
b：这是最不希望发生的情况，如果必须要进入老年代，也要尽量保证，该对象确实是长时间使用的对象，放入老年代的总对象创建量不会造成老年代的内存空间迅速长满发生Full GC，在这种情况下，可以通过定时脚本，在业务系统不繁忙情况下，主动触发full gc。
MGC 与 FGC 停顿时间长导致影响用户体验。其实对于停顿时间长的问题无非就两种情况：
a：gc 真实回收过程时间长，即real time时间长。这种时间长大部分是因为内存过大导致，从标记到清理的过程中需要对很大的空间进行操作，导致停顿时间长。这种情况，要考虑减少堆内存大小，包括新生代和老年代，比如之前使用16G的堆内存，可以考虑将16G 内存拆分为4个4G的内存区域，可以单台机器部署JVM逻辑集群，也可以为了降低GC回收时间，进行4节点的分布式部署，这里的分布式部署是为了降低 GC垃圾回收时间。
b：gc真实回收时间 real time 并不长，但是user time(用户态执行时间) 和 sys time（核心态执行时间）时间长，导致从客户角度来看，停顿时间过长。这种情况，要考虑线程是否及时达到了安全点，通过-XX：+PrintSafepointStatistics和-XX： PrintSafepointStatisticsCount=1去查看安全点日志，如果有长时间未达到安全点的线程，再通过参数-XX： +SafepointTimeout和-XX：SafepointTimeoutDelay=2000两个参数来找到大于2000ms到达安全点的线程，这里的2000ms可以根据情况自己设置，然后对代码进行针对的调整。除了安全点问题，也有可能是操作系统本身负载比较高，导致处理速度过慢，线程达到安全点时间长，因此需要同时检测操作系统自身的运行情况。
内存泄漏导致的MGC和FGC频繁，最终引发oom。纯代码级别导致的MGC和FGC频繁。如果是这种情况，那就只能对代码进行大范围的调整，这种情况就非常多了，而且会很糟糕。如大循环体中的new 对象，未使用合理容器进行对象托管导致对象创建频繁，不合理的数据结构使用等等。总之，JVM的调优无非就一个目的，在系统可接受的情况下达到一个合理的MGC和FGC的频率以及可接受的回收时间

内存模型

JDK1.6、JDK1.7、JDK1.8 内存模型演变

JDK 1.6：有永久代，静态变量存放在永久代上。
JDK 1.7：有永久代，但已经把字符串常量池、静态变量，存放在堆上。逐渐的减少永久代的使用。
JDK 1.8：无永久代，运行时常量池、类常量池，都保存在元数据区，也就是常说的元空间。但字符串常量池仍然存放在堆上。

堆和元空间

在 JDK 1.8 之后就不在堆上分配方法区了，元空间从虚拟机Java堆中转移到本地内存，默认情况下，元空间的大小仅受本地内存的限制，说白了也就是以后不会因为永久代空间不够而抛出OOM异常出现了。jdk1.8以前版本的 class和JAR包数据存储在 PermGen下面，PermGen 大小是固定的，而且项目之间无法共用，公有的 class，所以比较容易出现OOM异常。

线程的生命周期

共五步：
新建、就绪、运行、阻塞、死亡。
1、新建状态（New）：当程序使用new关键字创建了一个线程之后，该线程就处于新建状态。
2、就绪状态（Runnable）：调用start（）方法后，线程就会处于就绪状态；此时只能说明此线程已经做好了执行的就绪准备，表示可以运行了，但还不是正在运行的线程。
3、运行状态（Running）：当线程获得到JVM中线程调度器的调度时，线程就会处于运行状态，开始执行run()方法的线程执行体。
4、阻塞状态（Blocked）：这是线程仍处于活动状态但当前没有资格运行（因为一些原因，暂时放弃对CPU的使用权，停止执行）时的状态。
5、死亡状态（Dead）：当退出run（）方法时，线程就会自然死亡，处于终止或死亡状态，也就结束了生命周期。

面向对象的特征

1抽象性 2封装 3继承 4多态性

封装概念

封装就是将类里的某些信息隐藏，不允许外部程序直接调用，可以对成员变量更准确的控制；

继承概念

就是子类继承父类,表明子类是一种特殊的父类,并且具有父类所不具有的一些属性或方法

多态性

多态分为两种：(1)引用的多态、(2)方法的多态

引用的多态：父类的引用可以指向本类、子类的对象；
注意：子类的对象不可以指向父类的对象

方法的多态：

创建本类对象时，调用的方法为本类的方法；
创建子类对象时，调用的方法为子类重写的方法或者继承的方法；

注意：父类的引用调用的方法不能是子类独有的方法，必须是从父类继承的方法或重写父类的方法。

多态性的四种体现

1接口和接口的继承、 2类和类的继承、3重载、 4重写

重载在同一个类里同名形参列表不同，重写在实现类里面。

抽象类(abstract class)和接口(interface)有什么异同？

抽象类：
1.抽象类中可以定义构造器
2.可以有抽象方法和具体方法
3.接口中的成员全都是public的
4.抽象类中可以定义成员变量
5.有抽象方法的类必须被声明为抽象类，而抽象类未必要有抽象方法
6.抽象类中可以包含静态方法
7.一个类只能继承一个抽象类
接口：
1.接口中不能定义构造器
2.方法全部都是抽象方法
3.抽象类中的成员可以是 private、默认、protected、public
4.接口中定义的成员变量实际上都是常量
5.接口中不能有静态方法
6.一个类可以实现多个接口
相同：
1.不能够实例化
2.可以将抽象类和接口类型作为引用类型
3.一个类如果继承了某个抽象类或者实现了某个接口都需要对其中的抽象方法全部进行实现，否则该类仍然需要
被声明为抽象类

http中重定向和请求转发的区别？

本质区别：转发是服务器行为，重定向是客户端行为。

转发：浏览器地址栏不变，1次请求，request请求，可以访问web-inf,可以共享request请求域数据，只能跳转工程资源。
重定向：浏览器变化，2次请求，response响应，不能访问web-inf，不可以共享request请求域数据，可以跳转任意资源。

break和continue的区别？

break和continue都是用来控制循环的语句。
break用于完全结束一个循环，跳出循环体执行循环后面的语句。
continue用于跳过本次循环，执行下次循环。

SpringBoot的特点

Springboot嵌入的Tomcat 无需部署war文件
基于注解自动配置 Spring

SpringMVC的工作原理：

Synchronized

定义

Synchronized是Java语言的关键字，它保证同一时刻被Synchronized修饰的代码最多只有1个线程执行。

应用场景

synchronized如果加在方法上/对象上，那么，它作用的对象是非静态的，它取得的锁是对象锁；
synchronized如果作用的对象是一个静态方法或一个类，它取到的锁是类锁，这个类所有的对象用的是同一把锁。
每个对象只有一个锁，谁拿到这个锁，谁就可以运行它所控制的那段代码。

对象加锁实现原理

在Java的设计中，每一个Java对象就带了一把看不见的锁，可以叫做内部锁或者Monitor锁，Synchronized在JVM里的实现是基于进入和退出Monitor对象来实现方法同步和代码块同步的。Monitor可以把它理解为一个同步工具，所有的Java对象是天生的Monitor，Monitor监视器对象就是存在于每个Java对象的对象头MarkWord里面，也就是存储指针的指向，Synchronized锁便是通过这种方式获取锁的。
————————————————

ThreadLocal

定义

ThreadLocal叫做线程变量，这个变量对其他线程而言是隔离的，是当前线程独有的变量。ThreadLocal为变量在每个线程中都创建了一个副本，每个线程可以访问自己内部的副本变量。

ThreadLocal与Synchronized的区别

1、Synchronized用于线程间的数据共享，ThreadLocal用于线程间的数据隔离。

2、Synchronized是利用锁的机制，让变量或代码块在某一时该只能被一个线程访问，用于在多个线程间通信时能够获得数据共享。ThreadLocal为每一个线程都提供了变量的副本，让每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。

底层实现

在 Thread 类中嵌入一个 ThreadLocalMap，ThreadLocalMap 就是一个容器，存储的就是这个 Thread 类专享的数据。

线程池

底层运行原理

线程池就是控制运行的线程数量，处理过程中将任务放到队列，然后在线程创建后启动这些任务，如果线程数量超出了最大数量就排队等候，等其他线程执行完毕再从队列中取出任务执行。

线程池相当于银行网点，常驻核心数相当于今日当值窗口，线程池能够同时执行的最大线程数相当于银行所有的窗口，任务队列相当于银行的候客区，当今日当值窗口满了，多出来的客户去候客区等待，当候客区满了，银行加开窗口，候客区先来的客户去加班窗口，当银行所有的窗口满了，其他客户在候客区等待，同时拒绝其他客户进入银行。当用户少了，加班的窗口等待时间（相当于多余线程存活的时间）（等待时间的单位相当于unit参数）假设超过一个小时还是没有人来，就取消加班的窗口。

七大核心参数

底层在创建线程池的时候有七个参数：核心线程数，同时执行的最大线程数，多余线程存活时间，单位时间秒，任务队列，默认线程工厂，拒绝策略

maximumPoolsize：同时执行的最大线程数
keepAliveTime：多余线程存活时间，当前线程池数量超过核心线程数时，当前空闲时间达到多余线程存活时间的值的时候，多余空闲线程会被销毁到只剩核心线程数为止
unit：多余线程存活时间的单位
workQueue：任务队列，被提交但尚未被执行的任务
threadFactory：生成线程池的线程工厂
handler：拒绝策略，当队列满了并且工作线程数量大于线程池的最大线程数时，提供拒绝策略。

如何合理的配置核心线程数？

对于CPU密集型任务，由于CPU密集型任务的性质，导致CPU的使用率很高，如果线程池中的核心线程数量过多，会增加上下文切换的次数，带来额外的开销。因此，考虑到CPU密集型任务因为某些原因而暂停，这个时候有额外的线程能确保CPU这个时刻不会浪费，还可以增加一个CPU上下文切换。一般情况下：线程池的核心线程数量等于CPU核心数+1。例如需要大量的计算，视频渲染啊，仿真啊之类的。这个时候CPU就卯足了劲在运行，这个时候切换线程，反而浪费了切换的时间，效率不高。打个比方，你的大脑是CPU，你本来就在一本心思地写作业，多线程这时候就是要你写会作业，然后立刻敲一会代码，然后在P个图，然后在看个视频，然后再切换回作业。emmmm，过程中你还需要切换（收起来作业，拿出电脑，打开VS…）那你的作业怕是要写到挂科。这个时候你就该一门心思地写作业。

对于I/O密集型任务，由于I/O密集型任务CPU使用率并不是很高，可以让CPU在等待I/O操作的时去处理别的任务，充分利用CPU。一般情况下：线程的核心线程数等于2*CPU核心数。例如你需要陪小姐姐或者小哥哥聊天，还需要下载一个VS，还需要看博客。打个比方，小姐姐给你发消息了，回一下她，然后呢？她给你回消息肯定需要时间，这个时候你就可以搜索VS的网站，先下安装包，然后一看，哎呦，她还没给你回消息，然后看会自己的博客。小姐姐终于回你了，你回一下她，接着看我的博客，这就是类似于IO密集型。你可以在不同的“不烧脑”的工作之间切换，来达到更高的效率。而不是小姐姐不回我的信息，我就干等，啥都不干，就等，这个效率可想而知，也许，小姐姐根本就不会回复你。

对于混合型任务，由于包含2种类型的任务，故混合型任务的线程数与线程时间有关。在某种特定的情况下还可以将任务分为I/O密集型任务和CPU密集型任务，分别让不同的线程池去处理。一般情况下：线程池的核心线程数=(线程等待时间/线程CPU时间+1)*CPU核心数；

并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，我们的项目使用的时redis作为缓存（这类非关系型数据库还是挺好的）。增加服务器是第二步（一般政府项目的首先，因为不用对项目技术做大改动，求一个稳，但前提是资金充足），至于线程池的设置，设置参考 2 。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件（任务时间过长的可以考虑拆分逻辑放入队列等操作）对任务进行拆分和解耦。

实际创建线程池

java.util.concurrent 包里提供的 Executors 也可以用来创建线程池

newSingleThreadExecutos 单线程线程池，也就是线程池只有一个任务，这个我偶尔用一用
newFixedThreadPool(int nThreads) 固定大小线程的线程池
newCachedThreadPool() 无界线程池，这个就是无论多少任务，都创建线程来运行，所以队列相当于没用。

在实际使用的时候，选择线程池的时候尽量不用JDK提供的三种常见的创建方式
第一是 Executors 提供的线程池使用场景很有限，一般场景很难用到
第二他们也都是通过 ThreadPoolExecutor 创建的线程池，我直接用 ThreadPoolExecutor 创建线程池，可以理解原理，灵活度更高。
第三因为它的底层队列是Linked这个接近于无界，非常大，这样会堆积大量的请求，从而导致OOM，阿里巴巴开发手册推荐我们使用ThreadPoolExecutor去创建线程池。

Java虚拟机栈

每一个方法在执行的同时，都会创建出一个栈帧，用于存放局部变量表、操作数栈、动态链接、方法出口、线程等信息。方法从调用到执行完成，都对应着栈帧从虚拟机中入栈和出栈的过程。最终，栈帧会随着方法的创建到结束而销毁。

类加载机制和双亲委派机制

第一步，加载，一个Java源文件进行编译之后，成为一个class字节码文件存储在磁盘上面，这个时候jvm需要读取这个字节码文件，通过通过IO流读取字节码文件，这一步就是加载。

类加载器将.class文件加载到JVM，首先是看当前类是不是使用自定义加载类加载的，如果不是，就委派应用类加载器加载，如果有加载过这个class文件，那就不用再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类的扩展类加载器同理也会先检查自己是不是已经加载过，如果没有再往上，看看启动类加载器。到启动类加载器，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己加载不了，就会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException找不到类异常，这就是所谓的双亲委派机制。
这种机制可以避免，同路径下的同文件名的类，比如，自己写了一个java.lang.obejct，这个类和jdk里面的object路径相同，文件名也一样，这个时候，如果不使用双亲委派机制的话，就会出现不知道使用哪个类的情况，而使用了双亲委派机制，它就委派给父类加载器就找这个文件是不是被加载过，从而避免了上面这种情况的发生。

第二步，验证，JVM读到文件也不是直接运行，还需要校验加载进来的字节码文件是不是符合JVM规范

验证的第一步就是文件的格式验证，验证class文件里面的魔数和主次版本号，发现它是一个jvm可以支持的class文件并且它的主次版本号符合兼容性要求，所以验证通过。
然后又回到了加载，它会将class文件这个二进制静态文件转化到方法区里面，转化为方法区的时候，会有一个结构的调整，将静态的存储文件转化为运行时数据区，这个转化等于说又回到了加载。
接着到了方法区的运行时数据区以后，在java堆内存里面生成一个当前类的class对象，作为方法区里面这个类，被各种访问的一个入口。比如说object类，它是所有类都继承它，访问它，所以它也需要一个被各种类访问的入口。object类先加载，加载完成之后，它经过这一系列的操作，把自己java.lang.object放到这个堆里面，要让其他的类进行访问，这个也是加载。
接着到了验证里面的第二步元数据验证，它会对字节码描述的信息进行语义分析，比如：这个类是不是有父类，是不是实现了父类的抽象方法，是不是重写了父类的final方法，是不是继承了被final修饰的类等等。
第三步，字节码验证，通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，比如：操作数栈的数据类型与指令代码序列是不是可以配合工作，方法中的类型转换是不是有效等等。
第四步，符号引用验证：确保解析动作可以正确执行，比如说：通过符号引用是不是可以找到对应的类和方法，符号引用中类、属性、方法的访问性是不是能被当前类访问等，验证完成之后，需要做准备。

准备就是给类的静态变量分配内存，并赋予默认值。我们的类里，可能会包含一些静态变量，比如说public static int a = 12; 得给a这个变量分配个默认值 0，再比如public static User user = new User(); 给 static的变量User分配内存，并赋默认值null。如果是final修饰的常量，就不需要给默认值了，直接赋值就可以了。

然后就是解析，解析就是将符号引用变为直接引用，该阶段会把一些静态方法替换为指向数据储存在内存中的指针或者句柄，也就是所谓的直接引用，这个就是静态链接过程，是在初始化之前完成。有静态链接就有动态链接，动态链接是在程序运行期间完成将符号引用替换为直接引用，比如静态方法里面有个方法，在运行的时候，方法是存放在常量池中的符号，运行到这个符号，就是找这个符号对应的方法区，因为代码的指令是加载到方法区里面去的，最后把方法对应代码的地址放到栈帧中的动态链接里。

后面就是初始化了，初始化就是对类的静态变量初始化为指定的值并且会执行静态代码块。比如准备阶段的public static final int a = 12;这个变量，就是准备阶段给static变量a赋了默认值0，这一步就该把12赋值给它了。还有static的User public static User user = new User(); 把User进行实例化。

最后就是使用和卸载了，到此整个加载流程就走完了。

SQL优化

针对SQL进行调整，在写SQL的时候遵循最左前缀原则，向右匹配直到遇到范围查询（>、<、between、like）就停止匹配，范围列可以用到索引，但是范围列后面的列无法用到索引。
like以通配符%开头索引失效会变成全表扫描的操作。
如果查询条件中含有函数或表达式，将导致索引失效而进行全表扫描。
只要列中包含有 NULL 值都将不会被包含在索引中，复合索引中只要有一列含有 NULL 值，那么这一列对于此复合索引就是无效的。
不要使用select *，改用select加字段名称，因为select *走的聚集索引，会进行全表扫描，如果一定要使用select *的话，mysql至少使用5.6版本，这个版本有一个离散读的优化，离散读的优化是将离散度大的列放到联合索引的前面，举个例子，select * from user where staff_id = 2 and customer_id = 584，这个时候索引优化会将customer_id放到前面，因为它的离散度更高，可以通过select count(distinct customer_id),count(distinct staff_id) from user查看列的离散度。

5.6版本有一个ICP的优化，以往根据索引查找记录，再根据WHERE条件来过滤记录。使用ICP优化后，会在取出索引的同时，直接根据WHERE条件过滤，将WHERE的部分过滤操作放在了存储引擎层。在某些查询下可以大大减少上层SQL层对记录的索取，从而提高性能。

5.6版本还有一个MRR优化，是批量处理对键值的查询操作ICP优化，减少缓冲池中页被替换的次数，使数据访问变得较为顺序。辅助索引查询得到书签后，先对主键进行排序，再按序进行查找。

另外在写sql的时候，尽量使用它的一个执行计划，去看我们的索引是不是失效了。

索引失效的几种情况

如果条件中有or，即使其中有部分条件带索引也不会使用。
对于复合索引，如果不使用前列，后续列也将无法使用。
like以%开头。列类型是字符串，那一定要在条件中将数据使用引号引用起来，否则不使用索引。
where中索引列有运算，有函数的，不使用索引。
如果mysql觉得全表扫描更快的时候，数据少的情况下，不使用索引。

Redis知识点

多路复用

redis的多路复用模式

redis使用模型有：select、poll、epoll。这里简单讲二种。

应用对外提供服务的过程

一个应用程序, 想对外提供服务, 一般都是通过建立套接字监听端口来实现, 也就是socket。
应用对外提供服务的过程：

创建套接字
绑定端口号
开始监听
当监听到连接时, 调用系统read去读取内容，但是读取操作是阻塞的。

select

问题：如果主线程处理read，就不能接收其他连接了, 所以只能开新的线程去处理这个事情。而且read操作是调用系统函数, 需要进行进程的切换, 从用户进程切换到系统进程，连接少还好，连接多的话，无疑降低了性能。

解决方案：用户线程批量将要查询的连接发给操作系统，这个过程只发生一次进程的切换，用户线程告诉操作系统，需要哪些数据, 它遍历查找，然后将结果返回给用户线程，这就是select。

操作系统接收到一组文件描述符，然后批量处理这些文件描述符，有顺序的循环检查有没有数据，然后返回结果。无论是监听端口还是建立了连接，程序拿到的都是一个文件描述符，将这些文件描述符批量查询就是了。

epoll

问题：有10万个连接，其中有数据的只有一个，那就回有9999次无效的操作，每次查询都要把所有的都传过去, 10万个就要传10万。

解决方案：直接知道哪些连接是有数据的，然后操作系统通知用户线程，那个连接是可以直接拿到数据的，用户线程就直接通过这个连接去读数据就好了，不需要遍历，这就是epoll。

建立一个需要回调的连接，将需要监听的文件描述符都扔给操作系统，当有新数据到达时，会直接返回给用户线程。用户线程将监听的列表交给操作系统维护，这样当有新数据来的时候，操作系统知道这是你要的，等你下次来拿的时候，直接给你了，少去了上面的遍历。

多路复用的定义

“多路”指的是多个网络连接，“复用”指的是复用同一个线程。

采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗）。

多路复用的举例

redis 需要处理 3 个 IO 请求，同时把 3 个请求的结果返回给客户端，所以总共需要处理 6 个 IO 事件，由于 Redis服务端对于命令的处理是单线程的，同一时间只能处理一个 IO 事件。于是 redis 需要在合适的时间暂停对某个 IO 事件的处理，转而去处理另一个 IO 事件，这样 redis 就好比一个开关，当开关拨到哪个 IO 事件这个电路上，就处理哪个 IO 事件，其他 IO 事件就暂停处理了。这就是IO多路复用技术。用一句话总结就是，一个客户端建立好连接后，就可以立刻等待新的客户端连接，而不用阻塞在原客户端的 read 请求上。

多路复用的实现

select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。 redis的io模型主要是基于epoll实现的，不过它也提供了 select和poll的实现，默认采用epoll。

过程一：数据未就绪

多个客户端并发请求时，用户线程发起请求的时候，首先会将socket监听列表添加到select中，让select调用操作系统的API，这个过程就是从用户态到内核态，由于当前请求是交给了操作系统去处理，现在的用户线程这时候就空闲了，可以重新接收新的客户端请求。

操作系统等待select调用，当数据到达时，select函数被激活，操作系统将select函数的结果socket监听结果为可读，返回给用户线程，告诉用户线程这个连接可以读取数据了，这个时候用户线程才正式发起read请求，读取数据，这个读取数据的过程也是非阻塞的。

过程二：数据就绪

read 函数的效果是，如果没有数据到达时（到达网卡并拷贝到了内核缓冲区），立刻返回一个错误值（-1），而不是阻塞地等待。只有当操作系统告诉用户线程数据已经准备就绪的时候，数据从内核缓冲区拷贝到用户缓冲区才通知用户进程调用完成，返回结果，这个过程是阻塞的。对于用户线程来说，它可以注册多个socket监听，然后不断地调用select读取，操作系统找到用户线程需要的连接，这个连接里面监听到有用户线程所需要的数据，就会激活socket把结果返回给用户线程。

单线程模型

为什么redis使用单线程模型还能保证高性能？

第一个是因为redis 是纯内存操作，内存的响应时长是 100 纳秒左右，这是 redis 的 QPS 过万的重要基础。

第二个是因为redis 的核心是基于非阻塞的IO多路复用机制，单线程模型避免了线程切换和竞态产生的消耗，解决了多线程的切换性能损耗问题。

第三个是因为redis底层使用C语言实现，一般来说，C 语言实现的程序"距离"操作系统更近，执行速度相对会更快。

你是如何理解redis单线程模型的？

Redis 里面的单线程主要是 Redis 的网络 IO 和键值对读写，它是由一个线程来完成的，但是 Redis 的其他功能，比如说持久化、异步删除、集群数据同步等等，这些其实是由额外的线程执行的，这里的单线程主要是Redis 对外提供键值存储服务来说的。

主要流程是这样的：redis 会将每个客户端都关联一个指令队列，客户端的指令通过队列来按顺序处理，先到先处理,一个客户端指令队列中的指令是按顺序执行的。 redis 的每个客户端都关联一个响应队列，通过响应队列有顺序地将指令的返回结果返回给客户端，并且redis 同一时间每次都只能处理一个客户端队列中的指令或者响应。

Redis底层数据结构

简单字符串

先简单了解一下C语言是怎么处理字符串的：

在C语言中，字符串结束的标识是空字符，也就是’’，这会有一个问题，就是字符串的内容可能包括空字符串，这个时候是不是就没办法正确存取字符串的内容了，它有可能中途读取一半就完了。

除此之外，它还不记录字符串的长度，这也会有一系列问题，

如果需要获取字符串的长度通过遍历计数来获取的，这会导致它的时间复杂度会比较高。如果需要修改字符串，就要重新分配内存，不重新分配的话，字符串长度增大，超出给定的长度，这个时候会造成内存缓冲区溢出，字符串长度减小还会造成内存泄露。如果需要对两个字符串进行拼接，是通过调用strcat函数来实现的，如果没有给它分配足够长度的内存空间，就会直接导致缓冲区溢出。

既然C语言处理字符串有这么多的弊端，那么Redis它是怎么处理字符串的呢？

Redis专门创建了一种数据结构SDS，什么意思呢？simple dynamic string，简单字符串。

官方代码：

struct sdshdr{int len;int free;char buf[];}

这个对象有三个属性：

len表示字符串的长度
free表示还有多少长度剩余，就是下面buf数组中还有多少字符串未使用的字节数量
buf[]表示存储的字符串

问题一：这种数据结构有什么优势呢？跟C语言相比，改进了哪些问题？

长度和内存重新分配问题，C语言是不记录长度，而SDS它有len属性和free属性。len记录了字符串的长度，直接取值就可以了，不像C语言需要遍历。 如果需要对字符串进行修改的话，也不需要像C语言一样，直接重新分配内存，它可以通过len 属性检查内存空间是不是需要进行扩展内存，如果字符串长度增加，长度超过了len，就会增加相应的内存，接着修改。如果字符串长度缩短了，它也不会立马就重新分配内存，而是有一个free属性记录下来，等你后面什么时候用了，重新计算或者分配内存。结尾标识问题，C语言是以空字符串结尾标识的，而SDS是以len长度作为结尾标识的，避免了C语言无法正确读取字符串的问题。

链表

Redis的list类型的键值对底层数据结构是由链表构成的，那么链表是什么呢？

它是由一连串节点组成，没有顺序，不是连续的，每个节点由数据和一或两个用来指向上一个或下一个节点位置的链接组成，在每一个节点里存到下一个节点的指针，通过链表中的指针链接次序可以实现逻辑顺序。

链表也分好几种：单向链表、双端链表、双向链表、有序链表以及有迭代器的链表

单向链表：用户的操作（添加、删除、遍历）只能从链表头开始。向一个方向遍历，查找一个节点的时候从第一个节点开始访问下一个节点，一直访问到需要的位置，最后一个节点存储地址的部分指向空值。

双端链表：双端链表相对于单端链表多了一个特性：对最后一个链接点的引用

双向链表：单端链表只能从链表头开始正向遍历，双向链表可以逆向遍历，每个节点需要保存前一个节点和后一个节点的引用

有序链表：插入元素时，将插入的元素与头结点及其后面的结点比较，找到合适的位置插入。

有迭代器的链表：单链表的基本操作中，大部分要用到依次遍历单链表中的每一个元素。当你新增一个对单链表的操作并需要使用遍历时，你就得重新写一个for循环而实现遍历。所以将迭代（遍历）作为一种基本的ADT（抽象数据类型）操作。链表中用于处理遍历、访问和更新的方法封装到一个新的迭代器类中。

跳跃表

跳跃表：跳跃表基于有序链表的扩展，在链表上建索引，每两个结点提取一个结点到上一级，我们把抽出来的那一级叫作索引，每个跳跃表节点的层高都是1至32之间的随机数。

举例说明：

比如给一个长度为7的有序链表，节点值依次是1->3->4->5。取出所有值为奇数的节点作为关键节点（索引），这个时候要插入一个值是2的新节点，就不需要将节点一个个比较，只要比较1,3,5，确定了值在1和3之间，就可以快速插入。加一层索引之后，查找一个结点需要遍历的结点个数减少了，虽然增加了50%的额外空间，但是查找效率提高了，同理再加一级索引，这种链表加多级索引的结构，就是跳跃表。索引是占内存的，原始链表中存储的可能是大的对象，索引结点只要存储关键值和几个指针，并不需要存储对象，当节点本身比较大或者元素数量比较多的时候，优势必然会被放大，而缺点则可以忽略。

问题：当大量的新节点通过逐层比较，最终插入到原链表之后，上层的索引节点会慢慢的不够用，那么这个时候要怎么选取一部分节点提到上一层呢？

抛硬币法：随机决定新节点是否选拔，每向上提拔一层的几率是50%。

原因：跳跃表的删除和添加节点是无法预测的，不能保证索引绝对分步均匀，不过可以让大体趋于均匀。

插入节点的工作流程：跳跃表插入操作的时间复杂度是O（logN），空间复杂度是 O（N）。

第一步：新节点和上层索引节点逐个比较，找到原链表的插入位置，时间复杂度为O（logN）
第二步：把索引插入到原链表，时间复杂度为O（1）
第三步：随机决定新节点是否提升为上一级索引，结果为"正面"则提升，继续抛硬币，结果为"反面"则停止，时间复杂度为O（logN)

删除节点的工作流程：跳跃表删除操作的时间复杂度是O（logN）

第一步：自上而下，查找第一次出现节点的索引，并逐层找到每一层对应的节点。时间复杂度为O（logN）

第二步：删除每一层查找到的节点，如果该层只剩下1个节点，删除整个一层（原链表除外）。时间复杂度为O（logN）

跳跃表由zskiplistNode和skiplist两个结构组成，zskiplistNode用于表示跳跃表节点，zskiplist用于保存跳跃表节点的相关信息，比如节点的数量，以及指向表头节点和表尾节点的指针等等。

字典

顾名思义，通过字典（牛津字典等）前面的目录快速定位到所要查找的单词。

在C 语言中没有这种数据结构，所以这种数据结构是Redis自己创造的，字典中的键都是唯一的，通过键可以对值来进行查询或更改。底层是通过哈希表实现的，而哈希表又基于数组，类似于key-value的结构形式进行存储的，它的值通过哈希函数映射为数组的下标。

那什么是哈希函数呢？不急，我们慢慢道来。

前面我们讲了通过数组的方式存储值，那么数组的值和数组的下标怎么建立关联关系呢？或者说，我们怎么通过数组的下标找到数组的值呢？

在学习 ASCII 编码的时候，我们知道，a可以用97这个数值表示，b可以用98这个数值表示，以此类推，我们就可以通过单个字母用数字表达。

有了字母，那么一个单词由多个字母组成，它又该如何表达呢？

假设我有一本字典，它有10000个单词，我其中一个单词就是ab，使用ASCII编码进行表达。ab = 97 + 98 = 195
那么存储在数组中的下标为195，这就是字母表达的基本原理，但是如果只是这样还是远远不够的，因为会出现一个数组存储多个单词的情况。
举例说明：假设有个单词有 10 个字母，那么字典的某个单词为 zzzzzzzzzz ，转换为数字：zzzzzzzzzz = 26*10 = 260。

补充说明：这个时候会发现我一本字典里10000个单词，在260这个范围内肯定是不够存储10000个单词的，10000/260=39（38.4补一位），一个数组项它要存储39个单词。

解决方案：为了保证数值的唯一，让每个数组都能够只存储一个单词，进行升级，将单词表示的数拆开，27 的幂乘以这些位数，有26个可能的字符，以及空格，一共27个。

ab = 97乘以27的一次幂加上98乘以27的零次幂 = 27*97 + 98 = 2717。解决了数组存储多个单词的问题，又引出新的问题数组分配大空间太多了。

举例说明：假设有个单词有 10 个字母，那么字典的某个单词为 zzzzzzzzzz ，转换为数字：zzzzzzzzzz = 26的9次幂 = 7000000000000

补充说明：数组中只有小部分存放了单词，其他空间都是空着的

解决方案：将巨大的整数范围压缩到可接受的数组范围内，可以通过取余解决，一个整数被另一个整数除后的余数。

举例说明：假设要把从0-99的数字（用large表示），压缩为从0-9的数字（用number表示），后者有10个数，所以变量range 的值为10，这个转换的表达式为：

补充说明：number = large % range。当一个整数被 10 整除时，余数是在0-9之间，把从0-99的数压缩为从0-9的数，压缩率为 10 :1。

使用哈希函数向数组插入数据后，这个数组就是哈希表，它的值就是通过上面这种方式映射到数组的下标上的。

这也就是哈希函数的工作模式，它把一个大范围的数字哈希转化成一个小范围的数字，这个小范围的数对应着数组的下标。
但是这种工作模式会有一点问题：把大的数字范围压缩到小的数字范围，会有几个不同的单词哈希化到同一个数组下标，这就是所谓的哈希冲突。

问题：那么如何解决哈希冲突呢？

开放地址法：指定的数组范围大小是存储数据的两倍，有一半的空间是空的。

当冲突产生时，通过（线性探测、二次探测以及再哈希法）方法找到数组的一个空位，把单词填入，不用哈希函数得到数组的下标。线性探测中，如果哈希函数计算的原始下标是x, 线性探测就是x+1, x+2, x+3, 以此类推，而在二次探测中，探测的过程是x+1,
x+4, x+9, x+16。这二种方式都会有聚集情况。

什么是聚集呢？当哈希表快要满的时候，每插入新的数据，都要频繁的探测插入位置，很多位置都被前面插入的数据所占用了，这称为聚集。

再哈希法：依赖关键字的探测序列，把关键字用不同的哈希函数再做一遍哈希化，用这个结果作为步长，步长在整个探测中是不变的，不过不同的关键字使用不同的步长。

链地址法：数组的每个数据项都创建一个子链表或子数组，那么数组内不直接存放单词，当产生冲突时，新的数据项直接存放到这个数组下标表示的链表中。

整数集合：顾名思义，用来保存整数值类型的集合，保证元素不会重复。
定义：

typedef struct intset{//编码方式uint32_t encoding;//集合包含的元素数量uint32_t length;//保存元素的数组int8_t contents[];}intset;

contents数组声明为int8_t类型，但是contents数组并不保存任何int8_t类型的值，真正类型由encoding决定。比如：

encoding属性的值为INTSET_ENC_INT16，contents是int16_6类型的数组，数组里的每个项是int16_t类型的是整数值。
encoding属性的值为INTSET_ENC_INT32，contents是int32_t类型的数组，数组里的每个项是int32_t类型的整数值。
encoding属性的值为INTSET_ENC_INT64，contents是int64_t类型的数组，数组里的每个项是int64_t的整数值。

新增的元素类型比原集合元素类型的长度大的时候，根据新元素类型增加整数集合底层数组的容量，给新元素分配空间，将底层数组现有的所有元素都转成与新元素相同类型的元素，把转换后的元素放到正确的位置，整个元素顺序是有序的，能极大地节省内存。

压缩列表

压缩列表，它是特殊编码的连续内存块组成的顺序型数据结构，压缩列表有任意多个节点（entry），每个节点有一个字节数组或者一个整数值。

压缩列表不是用某种算法对数据进行压缩，它将数据按照一定规则编码，放在一块连续的内存区域，目的是节省内存。

压缩列表包含以下：
zlbytes：记录整个压缩列表占用的内存字节数。
zltail：记录压缩列表表尾节点距离压缩列表的初始地址有多少字节。
zllen：记录压缩列表包含的节点数量。
zlend：用来标记压缩列表的末端。
entryX：列表的节点，包含

previous_entry_ength：记录压缩列表前一个字节的长度。
encoding：节点的encoding保存的是节点的content的内容类型以及长度。
content：content区域用于保存节点的内容，节点内容类型和长度由encoding决定。

总结：
简单字符串：SDS作为redis专门为字符串存取开发的数据结构，有获取字符串长度快，杜绝了缓存区的溢出，减少了修改字符串长度时所需的内存重分配次数，二进制安全，兼容部分C函数
链表：用作列表键、发布与订阅、慢查询、监视器等功能实现。
字典：用哈希表实现，字典有两个哈希表，一个正常使用，另一个用于rehash时使用，链地址法解决哈希冲突。
跳跃表：表中的节点按照分值大小进行排序。
整数集合：底层由数组构成，升级特性能尽可能的节省内存。
压缩列表：顺序型数据结构。

Redis五大数据类型的应用场景

各数据类型应用场景

工作中有很多场景经常用到redis，比如在使用String类型的时候，字符串的长度不能超过512M，可以set存储单个值，也可以把对象转成json字符串存储；还有我们经常说到的分布式锁，就是通过setnx实现的，返回结果是1就说明获取锁成功，返回0就是获取锁失败，这个值已经被设置过。又或者是网站访问次数，需要有一个计数器统计访问次数，就可以通过incr实现。
除了字符串类型，还有hash类型，它比string类型操作消耗内存和cpu更小，更节约空间。像我之前做过的电商项目里面，购物车实现场景可以通过hset添加商品，hlen获取商品总数，hdel删除商品，hgetall获取购物车所有商品。另外如果缓存对象的话，修改多个字段就不需要像String类型那样，取出值进行类型转换，然后设值进行类型转换，把它转成字符串缓存进行了。
还有列表list这种类型，是简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部或者尾部，它的底层实际上是个链表结构。这种类型更多的是用在文章发布上面，类似微博消息和微信公众号文章，在我之前的项目里面也有用到，比如说我关注了二个媒体，这二个媒体先后发了新闻，我就可以看到先发新闻那家媒体的文章，它可以通过lpush+rpop队列这种数据结构实现先进先出，当然也可以通过lpush+lpop实现栈这种数据结构来到达先进后出的功能。
然后就是集合set，底层是字典实现的，查找元素特别快，另外set 数据类型不允许重复，利用这两个特性我们可以进行全局去重，比如在用户注册模块，判断用户名是否注册。可以通过sadd、smembers等命令实现微信抽奖小程序，微信微博点赞，收藏，标签功能。还可以利用交集、并集、差集的特性实现微博微信的关注模型，交集和并集很好理解，差集可以解释一下，就是用第一个集合减去其他集合的并集，剩下的元素，就是差集。举个微博关注模型的例子，我关注了张三和李四，张三关注了李四和王五，李四关注了我和王五。
我进入了张三的主页
查看共同关注的人（李四），取出我关注的人和张三关注的人，二个集合取交集得出结果是李四，就是通过SINTER交集实现的。
查看我可能认识的人（王五），取出我关注的人和张三关注的人，二个集合取并集得出结果是（张三，李四，王五），拿我关注的人（张三，李四）减去并集里的元素，剩下的王五就是我可能认识的人，可以通过并集和差集实现。
查看我关注的人也关注了他（王五），取出我关注的人他们关注的人，（李四，王五）（我，王五）的交集，就是王五。
最后就是有序集合zset，有序的集合，可以做范围查找，比如说排行榜，展示当日排行前十。

线程的创建及实现线程几种方式之间的区别

1:继承Therad类，
2、实现Runnable接口
3、实现Callable接口
4、使用线程池
5、继承Thread类，并重写里面的run方法

class A extends Thread{public void run(){for(int i=1;i<=100;i++){System.out.println("-----------------"+i);}}
}
A a = new A();
a.start();

实现Runnable接口，并实现里面的run方法

class B implements Runnable{public void run(){for(int i=1;i<=100;i++){System.out.println("-----------------"+i);}}
}
B b = new B();
Thread t = new Thread(b);
t.start();

实现Callable

class A implements Callable<String>{public String call() throws Exception{//...}
}
FutureTask<String> ft = new FutureTask<>(new A());
new Thread(ft).start();

线程池

ExcutorService es = Executors.newFixedThreadPool(10);
es.submit(new Runnable(){//任务});
es.submit(new Runnable(){//任务});
...
es.shutdown();

实现Runnable和实现Callable的区别？

实现Callable接口，任务可以有返回值，Runnable没有。
实现Callable接口，可以指定泛型，Runnable没有。
实现Callable接口，可以在call方法中声明异常，Runnable没有。

Runnable和Thread二者的区别？

实现Runnable接口的方式，更适合处理有共享资源的情况。
实现Runnable接口的方式，避免了单继承的局限性。

以下是注解

@Component 组件，没有明确的角色
@Service 在业务逻辑层使用（service层）
@Repository 在数据访问层使用（dao层）
@Controller 在展现层使用，控制器的声明（C）注入bean的注解，声明该类为SpringMVC中的Controller
@Autowired 由Spring提供，默认根据类型查找
@Resource 由JSR-250提供，默认根据名称查找
@Bean 注解在方法上，声明当前方法的返回值为一个bean，替代xml中的方式（方法上）
@Configuration 声明当前类为配置类，其中内部组合了@Component注解，表明这个类是一个bean（类上）
@ComponentScan 用于对Component进行扫描，相当于xml中的（类上）
@RequestMapping 用于映射Web请求，包括访问路径和参数（类或方法上）
@ResponseBody 支持将返回值放在response内，而不是一个页面，通常用户返回json数据（返回值旁或方法上）
@RequestBody 允许request的参数在request体中，而不是在直接连接在地址后面。（放在参数前）
@PathVariable 用于接收路径参数，比如@RequestMapping(“/hello/{name}”)申明的路径，将注解放在参数中前，即可获取该值，通常作为Restful的接口实现方法。
@RestController 该注解为一个组合注解，相当于@Controller和@ResponseBody的组合，注解在类上，意味着，该Controller的所有方法都默认加上了@ResponseBody。

==和equals的区别？

equals和== 最大的区别是一个是方法一个是运算符。
==：如果比较的对象是基本数据类型，则比较的是数值是否相等；如果比较的是引用数据类型，则比较的是对象
的地址值是否相等。
equals()：用来比较方法两个对象的内容是否相等。
注意：equals 方法不能用于基本数据类型的变量，如果没有对 equals 方法进行重写，则比较的是引用类型的变
量所指向的对象的地址。

final、finally、finalize的区别？

1）final：用于声明属性，方法和类，分别表示属性不可变，方法不可覆盖，被其修饰的类不可继承。
2）finally：异常处理语句结构的一部分，表示总是执行。
3）finalize：Object类的一个方法，在垃圾回收器执行的时候会调用被回收对象的此方法，可以覆盖此方法
提供垃圾收集时的其他资源回收，例如关闭文件等。该方法更像是一个对象生命周期的临终方法，当该方法
被系统调用则代表该对象即将“死亡”，但是需要注意的是，我们主动行为上去调用该方法并不会导致该对
象“死亡”，这是一个被动的方法（其实就是回调方法），不需要我们调用。

String 、StringBuilder 、StringBuffer的区别？

Java平台提供了两种类型的字符串：String和StringBuffer/StringBuilder，它们都可以储存和操作字符串，区别
如下。
1）String是只读字符串，也就意味着String引用的字符串内容是不能被改变的。初学者可能会有这样的误解：如上，字符串str明明是可以改变的呀！其实不然，str仅仅是一个引用对象，它指向一个字符串对象“abc”。第
二行代码的含义是让 str 重新指向了一个新的字符串“bcd”对象，而“abc”对象并没有任何改变，只不过该对象已
经成为一个不可及对象罢了。
2）StringBuffer/StringBuilder 表示的字符串对象可以直接进行修改。
3）StringBuilder是Java5中引入的，它和 StringBuffer的方法完全相同，区别在于它是在单线程环境下使用的，
因为它的所有方法都没有被synchronized修饰，因此它的效率理论上也比StringBuffer要高。

GET和POST的区别？

GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间
以&相连，如：login.action?name=zhagnsan&password=123456。POST把提交的数据则放置在是HTTP包的包
体中。
GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据。
3.POST的安全性要比GET的安全性高。

Cookie和Session的区别

Cookie 是 web 服务器发送给浏览器的一块信息，浏览器会在本地一个文件中给每个 web 服务器存储 cookie。
Session 是存储在 web 服务器端的一块信息。

1、无论客户端做怎样的设置，session都能够正常工作。当客户端禁用cookie时将无法使用cookie。
2、在存储的数据量方面：session能够存储任意的java对象，cookie只能存储String类型的对象。

CPU飙高系统反应慢怎么排查？

1.CPU是整个电脑的核心计算资源，对于一个应用进程来说，CPU的最小执行单元是线程。

2.导致CPU飙高的原因有几个方面

CPU上下文切换过多，对于CPU来说，同一时刻下每个CPU核心只能运行一个线程，如果有多个线程要执行，CPU只能通过上下文切换的方式来执行不同的线程。上下文切换需要做两个事情
保存运行线程的执行状态
让处于等待中的线程执行

这两个过程需要CPU执行内核相关指令实现状态保存，如果较多的上下文切换会占据大量CPU资源，从而使得cpu无法去执行用户进程中的指令，导致响应速度下降。在Java中，文件IO、网络IO、锁等待、线程阻塞等操作都会造成线程阻塞从而触发上下文切换
CPU资源过度消耗，也就是在程序中创建了大量的线程，或者有线程一直占用CPU资源无法被释放，比如死循环！
CPU利用率过高之后，导致应用中的线程无法获得CPU的调度，从而影响程序的执行效率！

3.既然是这两个问题导致的CPU利用率较高，于是我们可以通过top命令，找到CPU利用率较高的进程，在通过Shift+H找到进程中CPU消耗过高的线程，这里有两种情况。

①、CPU利用率过高的线程一直是同一个，说明程序中存在线程长期占用CPU没有释放的情况，这种情况直接通过jstack获得线程的Dump日志，定位到线程日志后就可以找到问题的代码。
②、CPU利用率过高的线程id不断变化，说明线程创建过多，需要挑选几个线程id，通过jstack去线程dump日志中排查。

4.最后有可能定位的结果是程序正常，只是在CPU飙高的那一刻，用户访问量较大，导致系统资源不够。