比较全面的中级Java面试题

什么是线程死锁？死锁如何产生？如何避免线程死锁？

死锁的介绍：

线程死锁是指因为两个或者多个线程互相持有对方所须要的资源，致使这些线程处于等待状态，没法前往执行。当线程进入对象的synchronized代码块时，便占有了资源，直到它退出该代码块或者调用wait方法，才释放资源，在此期间，其余线程将不能进入该代码块。当线程互相持有对方所须要的资源时，会互相等待对方释放资源，若是线程都不主动释放所占有的资源，将产生死锁。

死锁的产生的一些特定条件：

一、 互斥条件：进程对于所分配到的资源具备排它性，即一个资源只能被一个进程占用，直到被该进程释放 。

二、 请求和保持条件：一个进程因请求被占用资源而发生阻塞时，对已得到的资源保持不放。

三、 不剥夺条件：任何一个资源在没被该进程释放以前，任何其余进程都没法对他剥夺占用。

四、 循环等待条件：当发生死锁时，所等待的进程一定会造成一个环路（相似于死循环），形成永久阻塞。

如何避免：

一、 加锁顺序：

当多个线程须要相同的一些锁，可是按照不一样的顺序加锁，死锁就很容易发生。若是能确保全部的线程都是按照相同的顺序得到锁，那么死锁就不会发生。固然这种方式须要你事先知道全部可能会用到的锁，然而总有些时候是没法预知的。

二、 加锁时限：

加上一个超时时间，若一个线程没有在给定的时限内成功得到全部须要的锁，则会进行回退并释放全部已经得到的锁，而后等待一段随机的时间再重试。可是若是有很是多的线程同一时间去竞争同一批资源，就算有超时和回退机制，仍是可能会致使这些线程重复地尝试但却始终得不到锁。

三、 死锁检测：

死锁检测即每当一个线程得到了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此以外，每当有线程请求锁，也须要记录在这个数据结构中。死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁而且锁超时也不可行的场景。

notify和notifyAll区别

他们的做用都是通知处于等待该对象的线程。

一、 notifyAll使全部原来在该对象上等待被notify的线程通通退出wait的状态，变成等待该对象上的锁，一旦该对象被解锁，他们就会去竞争。

二、 notify是通知其中一个线程，不会通知全部的线程。

谈一谈对MySQL InnoDB的认识

介绍：

InnoDB引擎是MySQL数据库的一个重要的存储引擎,和其余存储引擎相比,InnoDB引擎的优势是支持兼容ACID的事务(相似于PostgreSQL),以及参数完整性(有外键)等。如今Innobase实行双认证受权.MySQL5.5.5之后默认的存储引擎都是InnoDB引擎。

特色是：

一、 具备较好的事务支持：支持4个事务隔离级别，支持多版本读

二、 行级锁定：经过索引实现，全表扫描仍然会是表锁，注意间隙锁的影响

三、 读写阻塞与事务隔离级别相关

四、 具备很是高效的缓存特性：能缓存索引，也能缓存数据

五、 整个表和主键以Cluster方式存储，组成一颗平衡树

六、 全部Secondary Index都会保存主键信息

适用场景：

一、 须要事务支持（具备较好的事务特性）

二、 行级锁定对高并发有很好的适应能力，但须要确保查询是经过索引完成

三、 数据更新较为频繁的场景

四、 数据一致性要求较高

五、 硬件设备内存较大，能够利用InnoDB较好的缓存能力来提升内存利用率，尽量减小磁盘IO

谈一谈数据库事务的隔离级别？

一、 Read uncommitted（读未提交）就是一个事务能够读取另外一个未提交事务的数据。

二、 Read committed（读提交）就是一个事务要等另外一个事务提交后才能读取数据。

三、 Repeatable read（重复读）就是在开始读取数据（事务开启）时，再也不容许修改操做。

四、 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）中表的每一行只包含一个实例的信息。简而言之，第一范式要求数据表中的每一列（每一个字段）必须是不可拆分的最小单元。

二、 第二范式（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类型的分数，用来排序

总结

以上就是这篇文章的所有内容了，但愿本文的内容对你们的学习或者工做具备必定的参考学习价值