查缺补漏

JDK1.8新增内容

1. 速度更快 – 红黑树 尾插双链表 防止死循环
2. 代码更少 – Lambda
3. 强大的Stream API – Stream
4. 便于并行 – Parallel
5. 最大化减少空指针异常 – Optional

HashMap多线程死循环

多线程put后可能导致get死循环，多个线程put的时候造成了某个key值Entry key List的死循环。

TreeMap线程安全吗

TreeMap线程不安全，线程安全使用ConcurrentSkipListMap

ConcurrentHashMap的实现

jdk1.7
ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成。Segment是一种可重入锁ReentrantLock，在ConcurrentHashMap里扮演锁的角色，HashEntry则用于存储键值对数据。一个ConcurrentHashMap里包含一个Segment数组，Segment的结构和HashMap类似，是一种数组和链表结构， 一个Segment里包含一个HashEntry数组，每个HashEntry是一个链表结构的元素， 每个Segment守护者一个HashEntry数组里的元素,当对HashEntry数组的数据进行修改时，必须首先获得它对应的Segment锁。

在jdk1.8中主要做了2方面的改进
改进一：取消segments字段，直接采用transient volatile HashEntry<K,V>[] table保存数据，采用table数组元素作为锁，从而实现了对每一行数据进行加锁，进一步减少并发冲突的概率。
改进二：将原先table数组＋单向链表的数据结构，变更为table数组＋单向链表＋红黑树的结构。对于hash表来说，最核心的能力在于将key hash之后能均匀的分布在数组中。如果hash之后散列的很均匀，那么table数组中的每个队列长度主要为0或者1。但实际情况并非总是如此理想，虽然ConcurrentHashMap类默认的加载因子为0.75，但是在数据量过大或者运气不佳的情况下，还是会存在一些队列长度过长的情况，如果还是采用单向列表方式，那么查询某个节点的时间复杂度为O(n)；因此，对于个数超过8(默认值)的列表，jdk1.8中采用了红黑树的结构，那么查询的时间复杂度可以降低到O(logN)，可以改进性能。

volatile

volatile关键字其实就两个作用：（1）保证变量的可见性。（2）防止指令重排。而针对变量的可见性我们知道是读volatile变量的时候直接从内存中读
指令重排包括编译重排和运行重排，单线程不会有影响多线程可能对结果有影响（也可能是可见性）
在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。
volatile通过插入内存屏障来刷新缓存，防止指令重排。

CAS底层原理

volitile的写操作是安全的，因为他在写入的时候lock声言会锁住cpu总线导致其他CPU不能访问内存（现在多用缓存一致性协议，处理器嗅探总线上传播的数据来判断自己缓存的值是否过期），所以，写入的时候若其他cpu修改了内存值，那么写入会失败。上面的问题中，由于cpu1的CAS指令执行一半的时候cpu2火速修改了变量的值，因此这就让该变量在所有cpu上的缓存失效，cpu1在进行写入操作的时候，也会发现自己的缓存失效，那么CAS操作就会失败（在java的automicinteger中，会不停的CAS直到成功）。

抽象的队列式的同步器(AQS)

它维护了一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）
以ReentrantLock为例，state初始化为0，表示未锁定状态。A线程lock()时，会调用tryAcquire()独占该锁并将state+1。此后，其他线程再tryAcquire()时就会失败，直到A线程unlock()到state=0（即释放锁）为止，其它线程才有机会获取该锁。当然，释放锁之前，A线程自己是可以重复获取此锁的（state会累加），这就是可重入的概念。但要注意，获取多少次就要释放多么次，这样才能保证state是能回到零态的。

QPS多少

单体500-2000 1000

线程池原理

优点：1.减少创建销毁次数，重复利用节省资源。2.管理线程工作状态控制并发，防止创建太多线程卡顿。
原理：1.核心线程是否工作，没有则创建。2.工作队列是否已满，没满则放入。3.线程池是否已满，没有则创建，有则饱和策略。
核心线程数 最大线程数 非核心线程闲置时间 任务队列 线程工厂 拒绝添加
newCachedThreadPool 创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixedThreadPool 建一个指定工作线程数量的线程池。每当提交一个任务就创建一个工作线程，如果工作线程数量达到线程池初始的最大数，则将提交的任务存入到池队列中。
package test;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadPoolExecutorTest {
public static void main(String[] args) {
ExecutorService fixedThreadPool = Executors.newFixedThreadPool(3);
for (int i = 0; i < 10; i++) {
final int index = i;
fixedThreadPool.execute(new Runnable() {
public void run() {
try {
System.out.println(index);
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
}
}
}
newSingleThreadExecutor 创建一个单线程化的Executor，即只创建唯一的工作者线程来执行任务，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。如果这个线程异常结束，会有另一个取代它，保证顺序执行。单工作线程最大的特点是可保证顺序地执行各个任务，并且在任意给定的时间不会有多个线程是活动的。
newScheduleThreadPool 创建一个定长的线程池，而且支持定时的以及周期性的任务执行，支持定时及周期性任务执行。

如果是CPU密集型的任务，我们应该设置数目较小的线程数，比如CPU数目加1。如果是IO密集型的任务，则应该设置可能多的线程数，由于IO操作不占用CPU，所以，不能让CPU闲下来。当然，如果线程数目太多，那么线程切换所带来的开销又会对系统的响应时间带来影响
最佳线程数目 = （线程等待时间与线程CPU时间之比 + 1）* CPU数目

垃圾回收机制

什么是CAP

所谓CAP原则，是指在分布式系统中Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）三者不能同时得到。

什么是ACID

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）

二阶段请求&三阶段请求

二阶段：请求阶段本地执行，写本地日志，协调者收到全部ok，发提交指令，进入提交阶段。
三阶段：发送请求，协调者收到全部ok，执行并记日志，发ack，收到ack无超时，提交。避免事务阻塞。

粘包拆包解决办法

消息定长；增加消息长读消息头；特殊字符结尾

为什么四次挥手

因为服务端有一次传数据的机会

静态内部类单例模式

一致性哈希

主要应用：分布式缓存、路由
hash值映射到环上，加虚拟节点，分布均匀，增删代价低。

什么是幂等

多次请求结果一致，资源不收影响

dubbo比spring cloud快的原因

1.底层协议占用带宽小。2.长连接节省握手时间。

大于小于会用到索引吗

如果你的add_time字段有索引，且该索引只有add_time字段，或者以add_time字段排在首位，那么你使用条件查询where add_time < 1477900000 时会走索引的。

RocketMQ

RocketMQ思路起源于Kafka，它对消息的可靠传输及事务性做了优化。

JAVA内存模型

Java内存模型中规定了所有的变量都存储在主内存中，每条线程还有自己的工作内存（可以与前面将的处理器的高速缓存类比），线程的工作内存中保存了该线程使用到的变量到主内存副本拷贝，线程对变量的所有操作（读取、赋值）都必须在工作内存中进行，而不能直接读写主内存中的变量。不同线程之间无法直接访问对方工作内存中的变量，线程间变量值的传递均需要在主内存来完成

grep 不区分大小写方法

-i

拦截器过滤器的区别

①拦截器是基于java的反射机制的，而过滤器是基于函数回调。
②拦截器不依赖与servlet容器，过滤器依赖与servlet容器。
③拦截器只能对action请求起作用，而过滤器则可以对几乎所有的请求起作用。
④拦截器可以访问action上下文、值栈里的对象，而过滤器不能访问。
⑤在action的生命周期中，拦截器可以多次被调用，而过滤器只能在容器初始化时被调用一次。
⑥拦截器可以获取IOC容器中的各个bean，而过滤器就不行，这点很重要，在拦截器里注入一个service，可以调用业务逻辑。
过滤器是在请求进入容器后，但请求进入servlet之前进行预处理的。请求结束返回也是，是在servlet处理完后，返回给前端之前。

聚集索引非聚集索引的区别，INNODB和MYISAM的主键索引与二级索引的对比

聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。

NIO的实现原理

synchronized原理，和lock的区别，ThreadLocal用法

事务隔离级别 MVCC原理

使用MVCC（多版本并发控制）。InnoDB为每行记录添加了一个版本号（系统版本号），每当修改数据时，版本号加一。
在读取事务开始时，系统会给事务一个当前版本号，事务会读取版本号<=当前版本号的数据，这时就算另一个事务插入一个数据，并立马提交，新插入这条数据的版本号会比读取事务的版本号高，因此读取事务读的数据还是不会变。

INNODB和MYISAM的区别

1. 事务支持
   MyISAM不支持事务，而InnoDB支持。InnoDB的AUTOCOMMIT默认是打开的，即每条SQL语句会默认被封装成一个事务，自动提交，这样会影响速度，所以最好是把多条SQL语句显示放在begin和commit之间，组成一个事务去提交。
   MyISAM是非事务安全型的，而InnoDB是事务安全型的，默认开启自动提交，宜合并事务，一同提交，减小数据库多次提交导致的开销，大大提高性能。
2. 存储结构
   MyISAM：每个MyISAM在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm文件存储表定义。数据文件的扩展名为.MYD (MYData)。索引文件的扩展名是.MYI (MYIndex)。
   InnoDB：所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB表的大小只受限于操作系统文件的大小，一般为2GB。
3. 存储空间
   MyISAM：可被压缩，存储空间较小。支持三种不同的存储格式：静态表(默认，但是注意数据末尾不能有空格，会被去掉)、动态表、压缩表。
   InnoDB：需要更多的内存和存储，它会在主内存中建立其专用的缓冲池用于高速缓冲数据和索引。
4. 可移植性、备份及恢复
   MyISAM：数据是以文件的形式存储，所以在跨平台的数据转移中会很方便。在备份和恢复时可单独针对某个表进行操作。
   InnoDB：免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump，在数据量达到几十G的时候就相对痛苦了。
5. 事务支持
   MyISAM：强调的是性能，每次查询具有原子性,其执行数度比InnoDB类型更快，但是不提供事务支持。
   InnoDB：提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
6. AUTO_INCREMENT
   MyISAM：可以和其他字段一起建立联合索引。引擎的自动增长列必须是索引，如果是组合索引，自动增长可以不是第一列，他可以根据前面几列进行排序后递增。
   InnoDB：InnoDB中必须包含只有该字段的索引。引擎的自动增长列必须是索引，如果是组合索引也必须是组合索引的第一列。
7. 表锁差异
   MyISAM：只支持表级锁，用户在操作myisam表时，select，update，delete，insert语句都会给表自动加锁，如果加锁以后的表满足insert并发的情况下，可以在表的尾部插入新的数据。
   InnoDB：支持事务和行级锁，是innodb的最大特色。行锁大幅度提高了多用户并发操作的新能。但是InnoDB的行锁，只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的。
   MyISAM锁的粒度是表级，而InnoDB支持行级锁定。简单来说就是, InnoDB支持数据行锁定，而MyISAM不支持行锁定，只支持锁定整个表。即MyISAM同一个表上的读锁和写锁是互斥的，MyISAM并发读写时如果等待队列中既有读请求又有写请求，默认写请求的优先级高，即使读请求先到，所以MyISAM不适合于有大量查询和修改并存的情况，那样查询进程会长时间阻塞。因为MyISAM是锁表，所以某项读操作比较耗时会使其他写进程饿死。
8. 全文索引
   MyISAM：支持(FULLTEXT类型的)全文索引
   InnoDB：不支持(FULLTEXT类型的)全文索引，但是innodb可以使用sphinx插件支持全文索引，并且效果更好。
   全文索引是指对char、varchar和text中的每个词（停用词除外）建立倒排序索引。MyISAM的全文索引其实没啥用，因为它不支持中文分词，必须由使用者分词后加入空格再写到数据表里，而且少于4个汉字的词会和停用词一样被忽略掉。
   另外，MyIsam索引和数据分离，InnoDB在一起，MyIsam天生非聚簇索引，最多有一个unique的性质，InnoDB的数据文件本身就是主键索引文件，这样的索引被称为“聚簇索引”
9. 表主键
   MyISAM：允许没有任何索引和主键的表存在，索引都是保存行的地址。
   InnoDB：如果没有设定主键或者非空唯一索引，就会自动生成一个6字节的主键(用户不可见)，数据是主索引的一部分，附加索引保存的是主索引的值。InnoDB的主键范围更大，最大是MyISAM的2倍。
10. 表的具体行数
    MyISAM：保存有表的总行数，如果select count() from table;会直接取出出该值。
    InnoDB：没有保存表的总行数(只能遍历)，如果使用select count() from table；就会遍历整个表，消耗相当大，但是在加了wehre条件后，myisam和innodb处理的方式都一样。
11. CURD操作
    MyISAM：如果执行大量的SELECT，MyISAM是更好的选择。
    InnoDB：如果你的数据执行大量的INSERT或UPDATE，出于性能方面的考虑，应该使用InnoDB表。DELETE 从性能上InnoDB更优，但DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除，在innodb上如果要清空保存有大量数据的表，最好使用truncate table这个命令。
12. 外键
    MyISAM：不支持
    InnoDB：支持
13. 查询效率
    没有where的count()使用MyISAM要比InnoDB快得多。因为MyISAM内置了一个计数器，count()时它直接从计数器中读，而InnoDB必须扫描全表。所以在InnoDB上执行count()时一般要伴随where，且where中要包含主键以外的索引列。为什么这里特别强调“主键以外”？因为InnoDB中primary index是和raw data存放在一起的，而secondary index则是单独存放，然后有个指针指向primary key。所以只是count()的话使用secondary index扫描更快，而primary key则主要在扫描索引同时要返回raw data时的作用较大。MyISAM相对简单，所以在效率上要优于InnoDB，小型应用可以考虑使用MyISAM。
    通过上述的分析，基本上可以考虑使用InnoDB来替代MyISAM引擎了，原因是InnoDB自身很多良好的特点，比如事务支持、存储 过程、视图、行级锁定等等，在并发很多的情况下，相信InnoDB的表现肯定要比MyISAM强很多。另外，任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。如果不是很复杂的Web应用，非关键应用，还是可以继续考虑MyISAM的，这个具体情况可以自己斟酌。
    MyISAM和InnoDB两者的应用场景：
14. MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
15. InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB，这样可以提高多用户并发操作的性能。
    但是实际场景中，针对具体问题需要具体分析，一般而言可以遵循以下几个问题：

• 数据库是否有外键？
• 是否需要事务支持？
• 是否需要全文索引？
• 数据库经常使用什么样的查询模式？在写多读少的应用中还是Innodb插入性能更稳定，在并发情况下也能基本，如果是对读取速度要求比较快的应用还是选MyISAM。
• 数据库的数据有多大？ 大尺寸倾向于innodb，因为事务日志，故障恢复。

联合索引效率顺序

ABC>AB>AC=A>BC

如何配置主从同步

1．在主服务器上，必须开启二进制日志机制和配置一个独立的ID
2．在每一个从服务器上，配置一个唯一的ID，创建一个用来专门复制主服务器数据的账号
3．在开始复制进程前，在主服务器上记录二进制文件的位置信息
4．如果在开始复制之前，数据库中已经有数据，就必须先创建一个数据快照（可以使用mysqldump导出数据库，或者直接复制数据文件）
5．配置从服务器要连接的主服务器的IP地址和登陆授权，二进制日志文件名和位置

初始化bean的方式

@PostConstruct > InitializingBean > init-method

bean生命周期

Spring对bean进行实例化，默认bean是单例；
Spring对bean进行依赖注入；
如果bean实现了BeanNameAware接口，spring将bean的id传给setBeanName()方法；
如果bean实现了BeanFactoryAware接口，spring将调用setBeanFactory方法，将BeanFactory实例传进来；
如果bean实现了ApplicationContextAware接口，它的setApplicationContext()方法将被调用，将应用上下文的引用传入到bean中；
如果bean实现了BeanPostProcessor接口，它的postProcessBeforeInitialization方法将被调用；
如果bean实现了InitializingBean接口，spring将调用它的afterPropertiesSet接口方法，类似的如果bean使用了init-method属性声明了初始化方法，该方法也会被调用；
如果bean实现了BeanPostProcessor接口，它的postProcessAfterInitialization接口方法将被调用；
此时bean已经准备就绪，可以被应用程序使用了，他们将一直驻留在应用上下文中，直到该应用上下文被销毁；

类加载机制 双亲委托模型

Java中ClassLoader的加载采用了双亲委托机制，采用双亲委托机制加载类的时候采用如下的几个步骤：

1. 当前ClassLoader首先从自己已经加载的类中查询是否此类已经加载，如果已经加载则直接返回原来已经加载的类。
   每个类加载器都有自己的加载缓存，当一个类被加载了以后就会放入缓存，等下次加载的时候就可以直接返回了。
2. 当前classLoader的缓存中没有找到被加载的类的时候，委托父类加载器去加载，父类加载器采用同样的策略，首先查看自己的缓存，然后委托父类的父类去加载，一直到bootstrp ClassLoader.
3. 当所有的父类加载器都没有加载的时候，再由当前的类加载器加载，并将其放入它自己的缓存中，以便下次有加载请求的时候直接返回。
   说到这里大家可能会想，Java为什么要采用这样的委托机制？理解这个问题，我们引入另外一个关于Classloader的概念“命名空间”， 它是指要确定某一个类，需要类的全限定名以及加载此类的ClassLoader来共同确定。也就是说即使两个类的全限定名是相同的，但是因为不同的ClassLoader加载了此类，那么在JVM中它是不同的类。明白了命名空间以后，我们再来看看委托模型。采用了委托模型以后加大了不同的 ClassLoader的交互能力，比如上面说的，我们JDK本生提供的类库，比如hashmap,linkedlist等等，这些类由bootstrp 类加载器加载了以后，无论你程序中有多少个类加载器，那么这些类其实都是可以共享的，这样就避免了不同的类加载器加载了同样名字的不同类以后造成混乱
   类装载器ClassLoader（一个抽象类）描述一下JVM加载class文件的原理机制。

类装载器就是寻找类或接口字节码文件进行解析并构造JVM内部对象表示的组件，在java中类装载器把一个类装入JVM，经过以下步骤：
1、装载：查找和导入Class文件 2、链接：其中解析步骤是可以选择的 （a）检查：检查载入的class文件数据的正确性 （b）准备：给类的静态变量分配存储空间 （c）解析：将符号引用转成直接引用 3、初始化：对静态变量，静态代码块执行初始化工作
类装载工作由ClassLoder和其子类负责。JVM在运行时会产生三个ClassLoader：根装载器，ExtClassLoader(扩展类装载器)和AppClassLoader，其中根装载器不是ClassLoader的子类，由C++编写，因此在java中看不到他，负责装载JRE的核心类库，如JRE目录下的rt.jar,charsets.jar等。ExtClassLoader是ClassLoder的子类，负责装载JRE扩展目录ext下的jar类包；AppClassLoader负责装载classpath路径下的类包，这三个类装载器存在父子层级关系****，即根装载器是ExtClassLoader的父装载器，ExtClassLoader是AppClassLoader的父装载器。默认情况下使用AppClassLoader装载应用程序的类
Java装载类使用“全盘负责委托机制”。“全盘负责”是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类所依赖及引用的类也由这个ClassLoder载入；“委托机制”是指先委托父类装载器寻找目标类，只有在找不到的情况下才从自己的类路径中查找并装载目标类。这一点是从安全方面考虑的，试想如果一个人写了一个恶意的基础类（如java.lang.String）并加载到JVM将会引起严重的后果，但有了全盘负责制，java.lang.String永远是由根装载器来装载，避免以上情况发生 除了JVM默认的三个ClassLoder以外，第三方可以编写自己的类装载器，以实现一些特殊的需求。类文件被装载解析后，在JVM中都有一个对应的java.lang.Class对象，提供了类结构信息的描述。数组，枚举及基本数据类型，甚至void都拥有对应的Class对象。Class类没有public的构造方法，Class对象是在装载类时由JVM通过调用类装载器中的defineClass()方法自动构造的。
为什么要使用这种双亲委托模式呢？
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时被加载，所以用户自定义类是无法加载一个自定义的ClassLoader。
思考：假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？
答案是否定的。我们不能实现。为什么呢？我看很多网上解释是说双亲委托机制解决这个问题，其实不是非常的准确。因为双亲委托机制是可以打破的，你完全可以自己写一个classLoader来加载自己写的java.lang.String类，但是你会发现也不会加载成功，具体就是因为针对java.*开头的类，jvm的实现中已经保证了必须由bootstrp来加载。
Tomcat违反双亲委托，但是有AppClassLoader检查基础类。

jstat命令

jstat -class vmid 看类加载统计
jstat -gc vmid 看垃圾回收统计

java堆细分

新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2
Edem : from : to = 8 : 1 : 1
当对象在 Eden ( 包括一个 Survivor 区域，这里假设是 from 区域 ) 出生后，在经过一次 Minor GC 后，如果对象还存活，并且能够被另外一块 Survivor 区域所容纳
( 上面已经假设为 from 区域，这里应为 to 区域，即 to 区域有足够的内存空间来存储 Eden 和 from 区域中存活的对象 )，则使用复制算法将这些仍然还存活的对象复制到另外一块 Survivor 区域 ( 即 to 区域 ) 中，然后清理所使用过的 Eden 以及 Survivor 区域 ( 即 from 区域 )，并且将这些对象的年龄设置为1，以后对象在 Survivor 区每熬过一次 Minor GC，就将对象的年龄 + 1，当对象的年龄达到某个值时 ( 默认是 15 岁，可以通过参数 -XX:MaxTenuringThreshold 来设定 )，这些对象就会成为老年代。
但这也不是一定的，对于一些较大的对象 ( 即需要分配一块较大的连续内存空间 ) 则是直接进入到老年代。
Full GC 是发生在老年代的垃圾收集动作，所采用的是标记-清除算法。
现实的生活中，老年代的人通常会比新生代的人 “早死”。堆内存中的老年代(Old)不同于这个，老年代里面的对象几乎个个都是在 Survivor 区域中熬过来的，它们是不会那么容易就 “死掉” 了的。因此，Full GC 发生的次数不会有 Minor GC 那么频繁，并且做一次 Full GC 要比进行一次 Minor GC 的时间更长。
另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片 ( 即不连续的内存空间 )，此后需要为较大的对象分配内存空间时，若无法找到足够的连续的内存空间，就会提前触发一次 GC 的收集动作。

HashMap和HashTable区别

HashMap线程不安全，可以存储null键和null值。
HashSet可以存null。
HashMap put先取hashcode所在的位置，再用equals比较值。

多线程

实现Runnable接口比继承Thread类所具有的优势：
1）：适合多个相同的程序代码的线程去处理同一个资源
2）：可以避免java中的单继承的限制
3）：增加程序的健壮性，代码可以被多个线程共享，代码和数据独立

Java 5之后，我们可以用Reentrantlock锁配合Condition对象上的await（）和signal（）或signalAll（）方法来实现线程间协作，比wait()和notify()更灵活，实现多个队列，它可以指定唤醒与自身Condition对象绑定在一起的任务。
wait()和notify()必须在synchronized的代码块中使用 因为只有在获取当前对象的锁时才能进行这两个操作 否则会报异常 而await()和signal()一般与Lock()配合使用

synchronized获取的互斥锁不仅互斥读写操作、写写操作，还互斥读读操作，而读读操作时不会带来数据竞争的，因此对对读读操作也互斥的话，会降低性能。Java 5中提供了读写锁，它将读锁和写锁分离，使得读读操作不互斥，获取读锁和写锁的一般形式如下：
ReadWriteLock rwl = new ReentrantReadWriteLock();
rwl.writeLock().lock() //获取写锁
rwl.readLock().lock() //获取读锁

线程的状态：

1. 新建状态（New）：新创建了一个线程对象。
2. 就绪状态（Runnable）：线程对象创建后，其他线程调用了该对象的start()方法。该状态的线程位于可运行线程池中，变得可运行，等待获取CPU的使用权。
3. 运行状态（Running）：就绪状态的线程获取了CPU，执行程序代码。
4. 阻塞状态（Blocked）：阻塞状态是线程因为某种原因放弃CPU使用权，暂时停止运行。直到线程进入就绪状态，才有机会转到运行状态。阻塞的情况分三种：
   （一）、等待阻塞：运行的线程执行wait()方法，JVM会把该线程放入等待池中。
   （二）、同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被别的线程占用，则JVM会把该线程放入锁池中。
   （三）、其他阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。
5. 死亡状态（Dead）：线程执行完了或者因异常退出了run()方法，该线程结束生命周期。

sleep和wait区别
从使用角度看，sleep是Thread线程类的方法，而wait是Object顶级类的方法。
sleep可以在任何地方使用，而wait只能在同步方法或者同步块中使用。
sleep,wait调用后都会暂停当前线程并让出cpu的执行时间，但不同的是sleep不会释放当前持有的对象的锁资源，到时间后会继续执行，而wait会放弃所有锁并需要notify/notifyAll后重新获取到对象锁资源后才能继续执行。
sleep需要捕获或者抛出异常，而wait/notify/notifyAll不需要。

死锁条件
互斥条件：一个资源每次只能被一个进程使用，即在一段时间内某 资源仅为一个进程所占有。此时若有其他进程请求该资源，则请求进程只能等待。
请求与保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源 已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放。
不可剥夺条件:进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能 由获得该资源的进程自己来释放（只能是主动释放)。
循环等待条件: 若干进程间形成首尾相接循环等待资源的关系

synchronized
进行了同步的方法（加锁方法）和没有进行同步的方法（普通方法）是互不影响的，一个线程进入了同步方法，得到了对象锁，其他线程还是可以访问那些没有同步的方法（普通方法）
这证明了类锁和对象锁是两个不一样的锁，控制着不同的区域，它们是互不干扰的。同样，线程获得对象锁的同时，也可以获得该类锁，即同时获得两个锁，这是允许的。

synchronized可以修饰方法和代码块，方法分为普通方法和静态方法，代码块括号里可以写this(当前对象)、其他对象、类

synchronized和lock区别
1Java的关键字，在jvm层面上。lock是一个类
2以获取锁的线程执行完同步代码，释放锁 2、线程执行发生异常，jvm会让线程释放锁。lock在finally中必须释放锁，不然容易造成线程死锁
3假设A线程获得锁，B线程等待。如果A线程阻塞，B线程会一直等待。lock分情况而定，Lock有多个锁获取的方式，具体下面会说道，大致就是可以尝试获得锁，线程可以不用一直等待
4无法判断锁状态。lock可以
5可重入 不可中断 非公平。lock可重入 可判断 可公平（两者皆可）
6少量同步。lock大量同步

原子类AtomicInteger incrementAndGet
1.先获取当前的value值
2.对value加一
3.先检查当前value是否等于current，如果相等，则意味着value没被其他线程修改过，更新并返回true。如果不相等，compareAndSet则会返回false，然后循环继续尝试更新。
底层cas,硬件支持

Object方法

wait notify notifyall hashcode equals toString getClass clone finalize

top指令能看啥

序号 列名 含义
1 PID 进程id
2 PPID 父进程id
3 RUSER Real user name
4 UID 进程所有者的用户id
5 USER 进程所有者的用户名
6 GROUP 进程所有者的组名
7 TTY 启动进程的终端名.不是从终端启动的进程则显示为 ?
8 PR 优先级
9 NI nice值.负值表示高优先级，正值表示低优先级
10 P 最后使用的CPU,仅在多CPU环境下有意义
11 %CPU 上次更新到现在的CPU时间占用百分比
12 TIME 进程使用的CPU时间总计,单位秒
13 TIME+ 进程使用的CPU时间总计,单位1/100秒
14 %MEM 进程使用的物理内存百分比
15 VIRT 进程使用的虚拟内存总量,单位kb,VIRT=SWAP+RES
16 SWAP 进程使用的虚拟内存中,被换出的大小,单位kb.
17 RES 进程使用的、未被换出的物理内存大小,单位kb,RES=CODE+DATA
18 CODE 可执行代码占用的物理内存大小,单位kb
19 DATA 可执行代码以外的部分(数据段+栈)占用的物理内存大小,单位kb
20 SHR 共享内存大小,单位kb
21 nFLT 页面错误次数
22 nDRT 最后一次写入到现在,被修改过的页面数.
23 S 进程状态:
D=不可中断的睡眠状态
R=运行
S=睡眠
T=跟踪/停止
Z=僵尸进程
24 COMMAND 命令名/命令行
25 WCHAN 若该进程在睡眠,则显示睡眠中的系统函数名
26 Flags 任务标志,参考 sched.h

CPU占比高原因

死循环
不断创建对象导致gc过于频繁
System.currentTimeMillis() 采用这种方式去做计时

CPU占比高解决办法

top看pid
ps aux |grep pid 或者ps -mp找线程tid
线程id转换成16进制 printf “%x\n” 775
查看java堆栈信息jstack 733 |grep 307 -A 30

垃圾回收器

ParNew收集器：Serial收集器的多线程版本（使用多条线程进行GC）
ParNew收集器是Serial收集器的多线程版本。
它是运行在server模式下的首选新生代收集器，除了Serial收集器外，目前只有它能与CMS收集器配合工作。CMS收集器是一个被认为具有划时代意义的并发收集器，因此如果有一个垃圾收集器能和它一起搭配使用让其更加完美，那这个收集器必然也是一个不可或缺的部分了。

G1收集器：
是当今收集器发展的最前言成果之一，知道jdk1.7，sun公司才认为它达到了足够成熟的商用程度。
优点：
　　它最大的优点是结合了空间整合，不会产生大量的碎片，也降低了进行gc的频率。二是可以让使用者明确指定停顿时间。（可以指定一个最小时间，超过这个时间，就不会进行回收了）它有了这么高效率的原因之一就是：对垃圾回收进行了划分优先级的操作，这种有优先级的区域回收方式保证了它的高效率。
如果你的应用追求停顿，那G1现在已经可以作为一个可尝试的选择；如果你的应用追求吞吐量，那G1并不会为你带来什么特别的好处。
注：以上所有的收集器当中，当执行GC时，都会stop the world，但是下面的CMS收集器却不会这样。

CMS收集器：（老年代收集器）
CMS收集器（Concurrent Mark Sweep：并发标记清除）是一种以获取最短回收停顿时间为目标的收集器。适合应用在互联网站或者B/S系统的服务器上，这类应用尤其重视服务器的响应速度，希望系统停顿时间最短。
CMS收集器运行过程：（着重实现了标记的过程）
（1）初始标记
　　根可以直接关联到的对象
　　速度快
（2）并发标记（和用户线程一起）
　　主要标记过程，标记全部对象
（3）重新标记
　　由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正
（4）并发清除（和用户线程一起）
　　基于标记结果，直接清理对象
整个过程如下图所示：
这里写图片描述
上图中，初始标记和重新标记时，需要stop the world。整个过程中耗时最长的是并发标记和并发清除，这两个过程都可以和用户线程一起工作。
优点：
　　并发收集，低停顿
缺点：
（1）导致用户的执行速度降低。
（2）无法处理浮动垃圾。因为它采用的是标记-清除算法。有可能有些垃圾在标记之后，需要等到下一次GC才会被回收。如果CMS运行期间无法满足程序需要，那么就会临时启用Serial Old收集器来重新进行老年代的收集。
（3）由于采用的是标记-清除算法，那么就会产生大量的碎片。往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次full GC。
疑问：既然标记-清除算法会造成内存空间的碎片化，CMS收集器为什么使用标记清除算法而不是使用标记整理算法：
答案：
CMS收集器更加关注停顿，它在做GC的时候是和用户线程一起工作的（并发执行），如果使用标记整理算法的话，那么在清理的时候就会去移动可用对象的内存空间，那么应用程序的线程就很有可能找不到应用对象在哪里。

Callable和Future

多线程结果收集，使用线程池，FutureList，循环获取future.get()

sql执行计划

explain
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL
type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般来说，得保证查询至少达到range级别，最好能达到ref。
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key： 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MYSQL认为必须检查的用来返回请求数据的行数
Extra：关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢

Spring-bean的循环依赖以及解决方式

getSingleton()的整个过程，Spring首先从一级缓存singletonObjects中获取。如果获取不到，并且对象正在创建中，就再从二级缓存earlySingletonObjects中获取。如果还是获取不到且允许singletonFactories通过getObject()获取，就从三级缓存singletonFactory.getObject()(三级缓存)获取，如果获取到了则：从singletonFactories中移除，并放入earlySingletonObjects中。其实也就是从三级缓存移动到了二级缓存。
“A的某个field或者setter依赖了B的实例对象，同时B的某个field或者setter依赖了A的实例对象”这种循环依赖的情况。A首先完成了初始化的第一步，并且将自己提前曝光到singletonFactories中，此时进行初始化的第二步，发现自己依赖对象B，此时就尝试去get(B)，发现B还没有被create，所以走create流程，B在初始化第一步的时候发现自己依赖了对象A，于是尝试get(A)，尝试一级缓存singletonObjects(肯定没有，因为A还没初始化完全)，尝试二级缓存earlySingletonObjects（也没有），尝试三级缓存singletonFactories，由于A通过ObjectFactory将自己提前曝光了，所以B能够通过ObjectFactory.getObject拿到A对象(虽然A还没有初始化完全，但是总比没有好呀)，B拿到A对象后顺利完成了初始化阶段1、2、3，完全初始化之后将自己放入到一级缓存singletonObjects中。此时返回A中，A此时能拿到B的对象顺利完成自己的初始化阶段2、3，最终A也完成了初始化，进去了一级缓存singletonObjects中，而且更加幸运的是，由于B拿到了A的对象引用，所以B现在hold住的A对象完成了初始化。

线程五种状态

创建 就绪 运行 阻塞 死亡

索引排序

只有order by 字段出现在where条件中时,才会利用该字段的索引而避免排序。

jsonp原理

ajax不能跨域，js可以跨域，

@Resource注解

SpringMVC生命周期

beanFactory

静态代理 动态代理 IOC AOP

红黑树实现

链表反转

冒泡排序 快排 二分查找

spring收藏

项目 遇到的困难 多线程高并发 qps

其它

项目抢券加密
数据库切换
缓存淘汰策略 持久化策略 过期策略
双工
Redis lru tomcat多线程
Eureka zookper区别 eureka停掉原理
算法 策略模式 桥接器模式 观察者模式
Innobd myisam 索引插入 外键 分库分表 redis单线程快 分布式锁 redis淘汰策略 缓存穿透 非公平锁
异常分类 memcache redis底层
线程同步 condition CountDownLatch CyclicBarrier mvcc 共享session linux 项目 redis 数据库锁 thrift Http 多线程 不停服拆表 nio秒杀难点