面试准备（一）

1、Servlet生命周期
Servlet的生命周期分为5个阶段：加载、创建、初始化、处理客户请求、卸载。
(1)加载：容器通过类加载器使用servlet类对应的文件加载servlet
(2)创建：通过调用servlet构造函数创建一个servlet对象
(3)初始化：调用init方法初始化
(4)处理客户请求：每当有一个客户请求，容器会创建一个线程来处理客户请求
(5)卸载：调用destroy方法让servlet自己释放其占用的资源

2、Bean对象的生命周期
（1）实例化一个Bean－－也就是我们常说的new；
（2）按照Spring上下文对实例化的Bean进行配置－－也就是IOC注入；
（3）如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String)方法，此处传递的就是Spring配置文件中Bean的id值；
（4）如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory(setBeanFactory(BeanFactory)传递的是Spring工厂自身（可以用这个方式来获取其它Bean，只需在Spring配置文件中配置一个普通的Bean就可以）；
（5）如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文（同样这个方式也可以实现步骤4的内容，但比4更好，因为ApplicationContext是BeanFactory的子接口，有更多的实现方法）；
（6）如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用那个的方法，也可以被应用于内存或缓存技术；
（7）如果Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法；
（8）如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；
注：以上工作完成以后就可以应用这个Bean了，那这个Bean是一个Singleton的，所以一般情况下我们调用同一个id的Bean会是在内容地址相同的实例，当然在Spring配置文件中也可以配置非Singleton，这里我们不做赘述。
（9）当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用那个其实现的destroy()方法；
（10）最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。

3、Redis单线程原因
多线程不一定比单线程效率高，多线程的本质就是CPU通过轮换时间片执行不同的线程，看似多个线程一起执行，但是却承担线程上下文切换的代价。
而对于Redis这样的内存数据库来说，没有上下文的切换的单线程效率是最高的。Redis用单个CPU绑定一块内存的数据，然后针对这块内存的数据进行多次读写操作都是在一个CPU上完成的。
redis是一种纯内存计算并且支持数据持久化的NoSQL数据库，单线程可以避免线程之间的上下文切换。redis的线程模型为多路IO复用机制，再加上其自建的内存管理系统和简单的数据结构，所以单线程的redis的速度已经足够快，其性能瓶颈主要体现在网络上。

4、多线程的实现方式
（1）JDK版本：2种。一种是继承Thread类，另一种是实现Runnable接口。
（2）Java多线程实现的方式有四种
1.继承Thread类，重写run方法
2.实现Runnable接口，重写run方法，实现Runnable接口的实现类的实例对象作为Thread构造函数的target
3.通过Callable和FutureTask创建线程
4.通过线程池创建线程

5、线程不安全的本质：
在操作系统中，线程是不拥有资源的，进程是拥有资源的。而线程是由进程创建的，一个进程可以创建多个线程，这些线程共享着进程中的资源。所以，当线程一起并发运行时，同时对一个数据进行修改，就可能会造成数据的不一致性

6、线程不安全解决途径
①加锁
(1)锁能使其保护的代码以串行的形式来访问，当给一个复合操作加锁后，能使其成 为原子操作。一种错误的思想是只要对写数据的方法加锁，其实这是错的，对数据 进行操作的所有方法都需加锁，不管是读还是写。
(2)加锁时需要考虑性能问题，不能总是一味地给整个方法加锁synchronized就了事了， 应该将方法中不影响共享状态且执行时间比较长的代码分离出去。
(3) 加锁的含义不仅仅局限于互斥，还包括可见性。为了确保所有线程都能看见最新 值，读操作和写操作必须使用同样的锁对象。
②不共享状态
(1) 无状态对象： 无状态对象一定是线程安全的，因为不会影响到其他线程。 (2) 线程关闭： 仅在单线程环境下使用。
③不可变对象
可以使用final修饰的对象保证线程安全，由于final修饰的引用型变量(除String外)不 可变是指引用不可变，但其指向的对象是可变的，所以此类必须安全发布，也即不能对 外提供可以修改final对象的接口。

7、ZooKeeper和Eureka的区别
ZooKeeper保证CP；
Eureka保证AP；
8、ConcurrentHashMap怎么实现线程安全？
java7中的基本设计理念就是切分成多个Segment块，默认是16个，也就是说并发度是16，可以初始化时显式指定，后期不能修改，每个Segment里面可以近似看成一个HashMap，每个Segment块都有自己独立的ReentrantLock锁，所以并发操作时每个Segment互不影响；java8中将Segment块换成了Node，每个Node有自己的锁，即每个Node都有自己的并发度；

9、乐观锁和悲观锁
乐观锁和悲观锁是两种思想，用于解决并发场景下的数据竞争问题。
乐观锁：乐观锁在操作数据时非常乐观，认为别人不会同时修改数据。因此乐观锁不会上锁，只是在执行更新的时候判断一下在此期间别人是否修改了数据：如果别人修改了数据则放弃操作，否则执行操作。（适合多写场景）
悲观锁：悲观锁在操作数据时比较悲观，认为别人会同时修改数据。因此操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据。（适合于多写场景）

10、公平锁和非公平锁
公平锁：多个线程按照申请锁的顺序去获得锁，线程会直接进入队列去排队，永远都是队列的第一位才能得到锁。

优点：所有的线程都能得到资源，不会饿死在队列中。
缺点：吞吐量会下降很多，队列里面除了第一个线程，其他的线程都会阻塞，cpu唤醒阻塞线程的开销会很大。
非公平锁：多个线程去获取锁的时候，会直接去尝试获取，获取不到，再去进入等待队列，如果能获取到，就直接获取到锁。

优点：可以减少CPU唤醒线程的开销，整体的吞吐效率会高点，CPU也不必取唤醒所有线程，会减少唤起线程的数量。
缺点：你们可能也发现了，这样可能导致队列中间的线程一直获取不到锁或者长时间获取不到锁，导致饿死。

11、自旋锁和锁的状态
锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁
自旋锁和自适应自旋；
线程的挂起和恢复会极大的影响开销。并且jdk官方人员发现，很多线程在等待锁的时候，在很短的一段时间就获得了锁，所以它们在线程等待的时候，并不需要把线程挂起，而是让他无目的的循环，一般设置10次。这样就避免了线程切换的开销，极大的提升了性能。
而适应性自旋，是赋予了自旋一种学习能力，它并不固定自旋10次一下。他可以根据它前面线程的自旋情况，从而调整它的自旋，甚至是不经过自旋而直接挂起。
偏向锁
多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让其获得锁的代价更低而引入了偏向锁。
当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。
轻量级锁
引入轻量级锁的主要目的是在多线程竞争不激烈的情况下，通过CAS竞争锁，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
重量级锁
重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高
偏向锁，轻量级锁，重量级锁比较
偏向锁：加锁和解锁不需要额外的消耗，和执行非同步方法比仅存在纳秒级的差距 如果线程间存在锁竞争，会带来额外的锁撤销的消耗 适用于只有一个线程访问同步块场景
轻量级锁：竞争的线程不会阻塞，提高了程序的响应速度 如果始终得不到锁竞争的线程使用自旋会消耗CPU 追求响应时间,锁占用时间很短
重量级锁：线程竞争不使用自旋，不会消耗CPU 线程阻塞，响应时间缓慢 追求吞吐量,锁占用时间较长。重量级锁不使用自旋，获取锁失败的线程直接进入阻塞状态
轻量级锁使用自旋

12、共享锁和排他锁
首先说明：数据库的增删改操作默认都会加排他锁，而查询不会加任何锁。
|–共享锁：对某一资源加共享锁，自身可以读该资源，其他人也可以读该资源（也可以再继续加共享锁，即 共享锁可多个共存），但无法修改。要想修改就必须等所有共享锁都释放完之后。语法为：
select * from table lock in share mode
|–排他锁：对某一资源加排他锁，自身可以进行增删改查，其他人无法进行任何操作。语法为：
select * from table for update

13、死锁和解决途径
死锁：两个进程分别等待对方占有的一个资源，于是两者都不能执行而处于永远等待，这种现象称为“死锁”；

解决死锁问题的三个方法：
死锁防止；
死锁避免；
死锁检测和恢复；
死锁产生的四个必要条件：
互斥条件: 进程应互斥使用资源，任一时刻一个资源仅为一个进程独占；
占有和等待条件:一个进程请求资源得不到满足而等待时，不释放已占有的资源；
不剥夺条件:任一进程不能从另一进程那里抢夺资源；
循环等待条件:存在一个循环等待链，每一个进程分别等待它前一个进程所持有的资源；
死锁的防止：
破坏四个必要条件之一，死锁就可防止；
破坏第一个条件，把独占型资源改造成共享性资源，使资源可同时访问而不是互斥使用。这是一个简单的办法，但对许多资源往往是不能做到的；
采用剥夺式调度方法可以破坏第三个条件，但剥夺式调度方法目前只适用于对主存资源和处理器资源的分配，而不适用于所有资源；
静态分配（预分配）：
所谓静态分配是指一个进程必须在执行前就申请它所要的全部资源，并且直到它所要的资源都得到满足之后才开始执行；
所有并发执行的进程要求的资源总和不超过系统拥有的资源数；
采用静态分配后，进程在执行中不再申请资源，因而不会出现占有了某些资源再等待另一些资源的情况，即破坏了第二个条件；
层次分配：
这种分配策略将阻止第四个条件的出现
在层次分配策略下，资源被分成多个层次；
一个进程得到某一层的一个资源后，它只能再申请在较高层的资源；
当一个进程要释放某层的一个资源时，必须先释放所占用的较高层的资源；
当一个进程获得了某一层的一个资源后，它想再申请该层中的另一个资源，那么，必须先释放该层中的已占资源；
死锁的避免
当不能防止死锁的产生时，如果能掌握并发进程中与每个进程有关的资源申请情况，仍然可以避免死锁的发生；
只需在为申请者分配资源前先测试系统状态，若把资源分配给申请者会产生死锁的话，则拒绝分配，否则接收申请，为它分配资源；（银行家算法）
死锁的检测
解决死锁问题的另一条途径是死锁检测方法；
这种方法对资源的分配不加限制，但系统定时运行一个“死锁检测”程序，判断系统内是否已出现死锁，若检测到死锁则设法加以解除；
14、数据库引擎MyISAM和InnoDB
MyISAM 操作数据都是使用的表锁，你更新一条记录就要锁整个表，导致性能较低，并发不高。当然同时它也不会存在死锁问题。
而 InnoDB 与 MyISAM 的最大不同有两点：一是InnoDB支持事务；二是 InnoDB 采用了行级锁。也就是你需要修改哪行，就可以只锁定哪行。
在 Mysql 中，行级锁并不是直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，如果一条sql 语句操作了主键索引，Mysql 就会锁定这条主键索引；如果一条语句操作了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。
InnoDB 行锁是通过给索引项加锁实现的，如果没有索引，InnoDB 会通过隐藏的聚簇索引来对记录加锁。也就是说：如果不通过索引条件检索数据，那么InnoDB将对表中所有数据加锁，实际效果跟表锁一样。因为没有了索引，找到某一条记录就得扫描全表，要扫描全表，就得锁定表。
15、NIO和BIO
BIO：同步阻塞式IO，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理，如果这个连接不做任何事情会造成不必要的线程开销，当然可以通过线程池机制改善。
NIO：同步非阻塞式IO，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。
AIO(NIO.2)：异步非阻塞式IO，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理。
16、七大原则
①、开闭原则
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
②、里氏代换原则
子类可以扩展父类的功能，但不能改变父类原有的功能。
它包含以下4层含义：
1.子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
2.子类中可以增加自己特有的方法。
3.当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
4.当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
③、依赖倒置原则
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。即针对接口编程，不要针对实现编程
在实际编程中，我们一般需要做到如下3点：
低层模块尽量都要有抽象类或接口，或者两者都有。
变量的声明类型尽量是抽象类或接口。
使用继承时遵循里氏替换原则
采用接口隔离原则对接口进行约束时，要注意以下几点：
1.接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
2.为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
3.提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
④、覆盖和组合原则
⑤、接口隔离原则
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
⑥、迪米特法原则
迪米特法则其根本思想，是强调了类之间的松耦合，类之间的耦合越弱,越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成影响，也就是说，信息的隐藏促进了软件的复用。
一句话总结就是：一个对象应该对其他对象保持最少的了解。
⑦、单一原则
定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责，应该仅有一个引起它变化的原因
遵循单一职责原的优点有：
1.可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2.提高类的可读性，提高系统的可维护性；
3.变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
17、Synchronize的底层实现方式
synchronized的三种应用方式
修饰实例方法，作用于当前实例加锁，进入同步代码前要获得当前实例的锁。
修饰静态方法，作用于当前类加锁，进入同步代码前要获得当前类的锁。
修饰代码块，指定加锁对象，对给定对象加锁，进入同步代码库前要获得给定对象。
synchronized的字节码指令
synchronized同步块使用了monitorenter和monitorexit指令实现同步，这两个指令，本质上都是对一个对象的监视器(monitor)进行获取，这个过程是排他的，也就是说同一时刻只能有一个线程获取到由synchronized所保护对象的监视器。
线程执行到monitorenter指令时，会尝试获取对象所对应的monitor所有权，也就是尝试获取对象的锁，而执行monitorexit，就是释放monitor的所有权。
18、JVM内存区域
方法区（Method Area）：
方法区属于线程共享的内存区域，又称Non-Heap（非堆），主要用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。在方法区中存在一个叫运行时常量池(Runtime Constant Pool）的区域，它主要用于存放编译器生成的各种字面量和符号引用，这些内容将在类加载后存放到运行时常量池中，以便后续使用。
JVM堆（Java Heap）：
Java 堆也是属于线程共享的内存区域，它在虚拟机启动时创建，是Java 虚拟机所管理的内存中最大的一块，主要用于存放对象实例，几乎所有的对象实例都在这里分配内存，注意Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做GC堆，如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError 异常。
程序计数器(Program Counter Register)：
属于线程私有的数据区域，是一小块内存空间，主要代表当前线程所执行的字节码行号指示器。字节码解释器工作时，通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
虚拟机栈(Java Virtual Machine Stacks)：
属于线程私有的数据区域，与线程同时创建，总数与线程关联，代表Java方法执行的内存模型。每个方法执行时都会创建一个栈桢来存储方法的的变量表、操作数栈、动态链接方法、返回值、返回地址等信息。每个方法从调用直结束就对于一个栈桢在虚拟机栈中的入栈和出栈过程。
本地方法栈(Native Method Stacks)：
本地方法栈属于线程私有的数据区域，这部分主要与虚拟机用到的 Native 方法相关，一般情况下，我们无需关心此区域。
19、GC回收对象判定
第一种方法是引用计数法 给对象增加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失效时，计数器就减1，任何时刻计数器为0的对象就是可能不再被使用的，即该对象就称为可被回收的对象。（java没在用）
第二种方法是可达性分析法
通过一系列的"GC Roots"对象作为起点进行搜索，如果在"GC Roots"和一个对象之间没有可达路径，则称该对象是不可达的。
可达性分析算法中的不可达对象，也并不是一定是垃圾，它们只是暂时处在"缓刑阶段"，要确定这个对象是垃圾，至少要经过两次标记过程；在第一次标记之后会进行一次筛选，筛选的条件是此对象有没有覆写 Object类的finalize() 方法，如果覆写了并且没执行过，那就执行finalize方法，如果在执行过程中，该对象和GC Roots对象可达则可逃离一次死亡，如果没有覆写或者覆写了已经被执行过了，那么该对象直接死亡。
能做GC Roots的对象：
①、常量引用的对象；
②、静态变量引用的对象；
③、虚拟机栈中引用的对象；
④、本地方法栈中引用的对象

20、GC回收算法
①、标记-清除

②、标记-整理

③、复制算法
21、类加载过程
1）编译:.java文件编译后生成.class字节码文件
2）加载：类加载器负责根据一个类的全限定名来读取此类的二进制字节流到JVM内部，并存储在运行时内存区的方法区，然后将其转换为一个与目标类型对应的java.lang.Class对象实例
3）链接: 原始的类信息平滑的转入jvm的过程
验证：格式（class文件规范） 语义（final类是否有子类） 操作
准备：静态变量赋初值和内存空间，final修饰的内存空间直接赋原值，此处不是用户指定的初值。
解析：符号引用转化为直接引用，分配地址
4）初始化
有父类先初始化父类，然后初始化自己；将static修饰代码执行一遍，如果是静态变量，则用用户指定值覆盖原有初值；如果是代码块，则执行一遍操作。

22、类加载的双亲委派模型
双亲委派模型的工作过程如下：
（1）当前类加载器从自己已经加载的类中查询是否此类已经加载，如果已经加载则直接返回原来已经加载的类。
（2）如果没有找到，就去委托父类加载器去加载（如代码c=parent.loadClass(name,false)所示）。父类加载器也会采用同样的策略，查看自己已经加载过的类中是否包含这个类，有就返回，没有就委托父类的父类去加载，一直到启动类加载器。因为如果父加载器为空了，就代表使用启动类加载器作为父加载器去加载。
（3）如果启动类加载器加载失败（例如在$JAVA_HOME/jre/lib里未查找到该class），则会抛出一个异常ClassNotFoundException，然后再调用当前加载器的findClass()方法进行加载。
双亲委派的原因：
（1）主要是为了安全性，避免用户自己编写的类动态替换 Java的一些核心类，比如 String。
（2）同时也避免了类的重复加载，因为 JVM中区分不同类，不仅仅是根据类名，相同的 class文件被不同的 ClassLoader加载就是不同的两个类。