什么是线程死锁？死锁如何产生？如何避免线程死锁？
死锁的介绍：
线程死锁是指由于两个或者多个线程互相持有对方所需要的资源，导致这些线程处于等待状态，无法前往执行。当线程进入对象的synchronized代码块时，便占有了资源，直到它退出该代码块或者调用wait方法，才释放资源，在此期间，其他线程将不能进入该代码块。当线程互相持有对方所需要的资源时，会互相等待对方释放资源，如果线程都不主动释放所占有的资源，将产生死锁。
死锁的产生的一些特定条件：
1、互斥条件：进程对于所分配到的资源具有排它性，即一个资源只能被一个进程占用，直到被该进程释放 。
2、请求和保持条件：一个进程因请求被占用资源而发生阻塞时，对已获得的资源保持不放。
3、不剥夺条件：任何一个资源在没被该进程释放之前，任何其他进程都无法对他剥夺占用。
4、循环等待条件：当发生死锁时，所等待的进程必定会形成一个环路（类似于死循环），造成永久阻塞。
如何避免：
1、加锁顺序：
当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就很容易发生。如果能确保所有的线程都是按照相同的顺序获得锁，那么死锁就不会发生。当然这种方式需要你事先知道所有可能会用到的锁，然而总有些时候是无法预知的。
2、加锁时限：
加上一个超时时间，若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。但是如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。
3、死锁检测：
死锁检测即每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
notify和notifyAll区别
他们的作用都是通知处于等待该对象的线程。
1、notifyAll使所有原来在该对象上等待被notify的线程统统退出wait的状态，变成等待该对象上的锁，一旦该对象被解锁，他们就会去竞争。
2、notify是通知其中一个线程，不会通知所有的线程。
谈一谈对MySQL InnoDB的认识
介绍：
InnoDB引擎是MySQL数据库的一个重要的存储引擎,和其他存储引擎相比,InnoDB引擎的优点是支持兼容ACID的事务(类似于PostgreSQL),以及参数完整性(有外键)等。现在Innobase实行双认证授权.MySQL5.5.5以后默认的存储引擎都是InnoDB引擎。
特点是：
1、具有较好的事务支持：支持4个事务隔离级别，支持多版本读
2、行级锁定：通过索引实现，全表扫描仍然会是表锁，注意间隙锁的影响
3、读写阻塞与事务隔离级别相关
4、具有非常高效的缓存特性：能缓存索引，也能缓存数据
5、整个表和主键以Cluster方式存储，组成一颗平衡树
6、所有Secondary Index都会保存主键信息
适用场景：
1、需要事务支持（具有较好的事务特性）
2、行级锁定对高并发有很好的适应能力，但需要确保查询是通过索引完成
3、数据更新较为频繁的场景
4、数据一致性要求较高
5、硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，尽可能减少磁盘IO
谈一谈数据库事务的隔离级别？
1、Read uncommitted（读未提交）就是一个事务可以读取另一个未提交事务的数据。
2、Read committed（读提交）就是一个事务要等另一个事务提交后才能读取数据。
3、Repeatable read（重复读）就是在开始读取数据（事务开启）时，不再允许修改操作。
4、Serializable（序列化）在该级别下，事务串行化顺序执行，可以避免脏读、不可重复读与幻读。是最高的事务隔离级别，但是这种事务隔离级别效率低下，比较耗数据库性能，一般不使用。
事务的作用就是保证数据的一致性、完整性。事务隔离级别越高，在并发下会产生的问题就越少，但同时付出的性能消耗也将越大，因此很多时候必须在并发性和性能之间做一个权衡。所以设立了几种事务隔离级别，以便让不同的项目可以根据自己项目的并发情况选择合适的事务隔离级别，对于在事务隔离级别之外会产生的并发问题，在代码中做补偿。
MySQL主备同步的基本原理
MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。
MySQL复制是基于主服务器在二进制日志中跟踪所有对数据库的更改。因此，要进行复制，必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器已经记录到日志的数据。
当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，并在本机上执行相同的更新。然后封锁并等待主服务器通知新的更新。从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新。
Java语言中一个显著的特点就是引入了垃圾回收机制，这个大家都清楚，垃圾回收的概念这里也不做介绍，重点是垃圾回收是在什么时候开始？对什么东西，做了什么事情？
GC何时开始：
所有的回收器类型都是基于分代技术来实现的，那就必须要清楚对象按其生命周期是如何划分的。
-
年轻代：划分为三个区域：原始区(Eden)和两个小的存活区(Survivor)，两个存活区按功能分为From和To。绝大多数的对象都在原始区分配，超过一个垃圾回收操作仍然存活的对象放到存活区。垃圾回收绝大部分发生在年轻代。
-
年老代：存储年轻代中经过多个回收周期仍然存活的对象，对于一些大的内存分配，也可能直接分配到永久代。
-
持久代：存储类、方法以及它们的描述信息，这里基本不产生垃圾回收。
有了以上这些铺垫之后开始回答GC何时开始：
Eden内存满了之后，开始Minor GC（从年轻代空间回收内存被称为 Minor GC）；升到老年代的对象所需空间大于老年代剩余空间时开始Full GC（但也可能小于剩余空间时，被HandlePromotionFailure参数强制Full GC）
对什么东西操作，即垃圾回收的对象是什么：
从root开始搜索没有可达对象，而且经过第一次标记、清理后，仍然没有复活的对象。
做了什么东西：
主要做了清理对象，整理内存的工作。具体的引申如下
垃圾回收器的类型：
-
串行垃圾回收器（Serial Garbage Collector）
-
并行垃圾回收器（Parallel Garbage Collector）
-
并发标记扫描垃圾回收器（CMS Garbage Collector）
-
G1垃圾回收器（G1 Garbage Collector）
垃圾回收算法：
-
引用计数法
-
标记清除法
-
复制算法
-
标记压缩算法
-
分代算法
-
分区算法
类在虚拟机中的加载过程
加载Loading：
通过一个类的全限定名来获取一个二进制字节流、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
验证Verification：
确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并不会危害虚拟机的自身安全。
准备Preparation：
正式为类变量分配内存并设置类变量初始值。
解析Resolution：
虚拟机将常量池内的符号引用替换为直接引用的过程。
初始化Initialization：
类加载过程的最后一步，到了这个阶段才真正开始执行类中定义的Java程序代码。
使用Using：
根据你写的程序代码定义的行为执行。
卸载Unloading：
GC负责卸载，这部分一般不用讨论。
强引用、软引用、弱引用、虚引用与GC的关系
强引用：new出的对象之类的引用，只要强引用还在，永远不会回收。
软引用：引用但非必须的对象，内存溢出异常之前回收。
弱引用：非必须的对象，对象只能生存到下一次垃圾收集发生之前。
虚引用：对生存时间无影响，在垃圾回收时得到通知。
说一下spring中Bean的作用域
singleton：
Spring IoC容器中只会存在一个共享的Bean实例，无论有多少个Bean引用它，始终指向同一对象。Singleton作用域是Spring中的缺省作用域。
prototype：
每次通过Spring容器获取prototype定义的bean时，容器都将创建一个新的Bean实例，每个Bean实例都有自己的属性和状态，而singleton全局只有一个对象。
request：
在一次Http请求中，容器会返回该Bean的同一实例。而对不同的Http请求则会产生新的Bean，而且该bean仅在当前Http Request内有效。
session：
在一次Http Session中，容器会返回该Bean的同一实例。而对不同的Session请求则会创建新的实例，该bean实例仅在当前Session内有效。
global Session：
在一个全局的Http Session中，容器会返回该Bean的同一个实例，仅在使用portlet context时有效。
说一下spring中Bean的生命周期
-
实例化一个Bean，也就是我们通常说的new。
-
按照Spring上下文对实例化的Bean进行配置，也就是IOC注入。
-
如果这个Bean实现了BeanNameAware接口，会调用它实现的setBeanName(String beanId)方法，此处传递的是Spring配置文件中Bean的ID。
-
如果这个Bean实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()，传递的是Spring工厂本身（可以用这个方法获取到其他Bean）。
-
如果这个Bean实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文。
-
如果这个Bean关联了BeanPostProcessor接口，将会调用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor经常被用作是Bean内容的更改，并且由于这个是在Bean初始化结束时调用After方法，也可用于内存或缓存技术。
-
如果这个Bean在Spring配置文件中配置了init-method属性会自动调用其配置的初始化方法。
-
如果这个Bean关联了BeanPostProcessor接口，将会调用postAfterInitialization(Object obj, String s)方法。
-
当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean接口，会调用其实现的destroy方法。
-
最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。
对Spring中依赖注入两种方式的认识
两种注入方式为：构造方法注入和设值注入
-
设值注入与传统的JavaBean的写法更相似，程序员更容易理解、接受，通过setter方式设定依赖关系显得更加直观、明显;
-
对于复杂的依赖关系，如果采用构造注入，会导致构造器过于臃肿，难以阅读。Spring在创建Bean实例时，需要同时实例化其依赖的全部实例，因而会产生浪费。而使用设置注入，则避免这下问题;
-
在某些属性可选的情况下，多参数的构造器更加笨拙，官方更鼓励使用设值注入。
-
构造注入可以在构造器中决定依赖关系的注入顺序，优先依赖的优先注入。
-
对于依赖关系无须变化的Bean，构造注入更有用处，因为没有setter方法，所有的依赖关系全部在构造器内设定，因此，不用担心后续代码对依赖关系的破坏。
-
构造注入使依赖关系只能在构造器中设定，则只有组件的创建者才能改变组件的依赖关系。对组件的调用者而言，组件内部的依赖关系完全透明，更符合高内聚的原则。
-
设值注入不会重写构造方法的值。如果我们对同一个变量同时使用了构造方法注入又使用了设置方法注入的话，那么构造方法将不能覆盖由设值方法注入的值。
-
建议采用以设值注入为主，构造注入为辅的注入策略。对于依赖关系无须变化的注入，尽量采用构造注入;而其他的依赖关系的注入，则考虑采用set注入。
Spring框架中都用到了哪些设计模式？
-
代理模式：在AOP和remoting中被用的比较多。
-
单例模式：在spring配置文件中定义的bean默认为单例模式。
-
模板方法模式：用来解决代码重复的问题。
-
前端控制器模式：Spring提供了DispatcherServlet来对请求进行分发。
-
依赖注入模式：贯穿于BeanFactory / ApplicationContext接口的核心理念。
-
工厂模式：BeanFactory用来创建对象的实例。
BeanFactory 和ApplicationContext的区别
BeanFactory和ApplicationContext都是接口，并且ApplicationContext是BeanFactory的子接口。
BeanFactory是Spring中最底层的接口，提供了最简单的容器的功能，只提供了实例化对象和拿对象的功能。而ApplicationContext是Spring的一个更高级的容器，提供了更多的有用的功能。
ApplicationContext提供的额外的功能：国际化的功能、消息发送、响应机制、统一加载资源的功能、强大的事件机制、对Web应用的支持等等。
加载方式的区别：BeanFactory采用的是延迟加载的形式来注入Bean；ApplicationContext则相反的，它是在Ioc启动时就一次性创建所有的Bean,好处是可以马上发现Spring配置文件中的错误，坏处是造成浪费。
数据库的三大范式
1 、第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。
在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式要求数据表中的每一列（每个字段）必须是不可拆分的最小单元。
2、 第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系。
3 、第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含其它表中已包含的非主关键字信息。简而言之，第三范式要求表中的每一列只与主键直接相关而不是间接相关，表中的每一列只能依赖于主键。
TCP和UDP的区别及其适用场景
首先说一下什么是TCP和UDP：
TCP是传输控制协议，提供的是面向连接、可靠的字节流服务。
UDP是用户数据报协议，是一个简单的面向数据报的运输层协议。
TCP和UDP的区别：
-
TCP面向连接的运输层协议，UDP无连接
-
TCP是可靠交付，UDP是尽最大努力交付
-
TCP面向字节流，UDP面向报文
-
TCP是点对点连接的，UDP一对一，一对多，多对多都可以
-
TCP适合用于网页，邮件等，UDP适合用于视频，语音广播等
TCP和UDP的适用场景：
整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。
当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，比如视频、广播等，这时就可以使用UDP。
说一下Spring的核心模块
-
Spring Core【核心容器】：核心容器提供了Spring的基本功能。核心容器的核心功能是用IOC容器来管理类的依赖关系。
-
Spring AOP【面向切面】：Spring的AOP模块提供了面向切面编程的支持。SpringAOP采用的是纯Java实现，采用基于代理的AOP实现方案，AOP代理由IOC容器负责生成、管理，依赖关系也一并由IOC容器管理。
-
Spring ORM【对象实体映射】：提供了与多个第三方持久层框架的良好整合。
-
Spring DAO【持久层模块】： Spring进一步简化DAO开发步骤，能以一致的方式使用数据库访问技术，用统一的方式调用事务管理，避免具体的实现侵入业务逻辑层的代码中。
-
Spring Context【应用上下文】：它是一个配置文件，为Spring提供上下文信息，提供了框架式的对象访问方法。
-
Spring Web【Web模块】：提供了基础的针对Web开发的集成特性。
-
Spring MVC【MVC模块】：提供了Web应用的MVC实现。Spring的MVC框架并不是仅仅提供一种传统的实现，它提供了一种清晰的分离模型。
（转发）forward与（重定向）redirect的区别
-
forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来,然后把这些内容再发给浏览器。浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址。
-
redirect是服务端根据逻辑，发送一个状态码，告诉浏览器重新去请求那个地址，所以地址栏显示的是新的URL。
-
forward转发页面和转发到的页面可以共享request里面的数据。
-
redirect不能共享数据。
-
redirect不仅可以重定向到当前应用程序的其他资源，还可以重定向到同一个站点上的其他应用程序中的资源，甚至是使用绝对URL重定向到其他站点的资源。
-
forward只能在同一个Web应用程序内的资源之间转发请求。
-
forward是服务器内部的一种操作。
-
redirect是服务器通知客户端，让客户端重新发起请求。
-
forward一般用于用户登陆的时候根据角色转发到相应的模块。
-
redirect一般用于用户注销登陆时返回主页面和跳转到其它的网站等。
-
forward效率高。
-
redirect效率低。
redis常用的五种数据类型
1.String（字符串）
String是简单的 key-value 键值对，value 不仅可以是 String，也可以是数字。它是Redis最基本的数据类型，一个redis中字符串value最多可以是512M。
2.Hash（哈希）
Redis hash 是一个键值对集合，对应Value内部实际就是一个HashMap，Hash特别适合用于存储对象。
3.List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。
底层实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。
4.Set（集合）
Redis的Set是String类型的无序集合，它的内部实现是一个 value永远为null的HashMap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。
5.zset(有序集合)
Redis zset 和 set 一样也是String类型元素的集合,且不允许重复的成员，不同的是每个元素都会关联一个double类型的分数，用来排序。