Java高级面试题及答案【第二部分】

谈一谈对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）

垃圾回收算法：

• 引用计数法

• 标记清除法

• 复制算法

• 标记压缩算法

• 分代算法

• 分区算法

以上这些，能够本身了解一下，这里列举几篇相关文章：
JVM的内存区域划分
JVM知识点梳理
JVM内存分配与回收
JVM内存管理机制
Java虚拟机学习 - 垃圾收集器

类在虚拟机中的加载过程

加载Loading：

经过一个类的全限定名来获取一个二进制字节流、将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构、在内存中生成一个表明这个类的java.lang.Class对象，做为方法区这个类的各类数据的访问入口。

验证Verification：

确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并不会危害虚拟机的自身安全。

准备Preparation：

正式为类变量分配内存并设置类变量初始值。

解析Resolution：

虚拟机将常量池内的符号引用替换为直接引用的过程。

初始化Initialization：

类加载过程的最后一步，到了这个阶段才真正开始执行类中定义的Java程序代码。

使用Using：

根据你写的程序代码定义的行为执行。

卸载Unloading：

GC负责卸载，这部分通常不用讨论。

以上这些抛砖引玉，欢迎留言更清晰的类加载过程，相关文章能够阅读：
类加载器详解
详解java类的生命周期
谈谈我对面向对象以及类与对象的理解

强引用、软引用、弱引用、虚引用与GC的关系

强引用：new出的对象之类的引用，只要强引用还在，永远不会回收。

软引用：引用但非必须的对象，内存溢出异常以前回收。

弱引用：非必须的对象，对象只能生存到下一次垃圾收集发生以前。

虚引用：对生存时间无影响，在垃圾回收时获得通知。

这个相对好理解了，相关阅读以下：
Java 如何有效地避免OOM：善于利用软引用和弱引用

说一下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中依赖注入两种方式的认识

两种注入方式为：构造方法注入和设值注入

1. 设值注入与传统的JavaBean的写法更类似，程序员更容易理解、接受，经过setter方式设定依赖关系显得更加直观、明显;

2. 对于复杂的依赖关系，若是采用构造注入，会致使构造器过于臃肿，难以阅读。Spring在建立Bean实例时，须要同时实例化其依赖的所有实例，于是会产生浪费。而使用设置注入，则避免这下问题;
   

3. 在某些属性可选的状况下，多参数的构造器更加笨拙，官方更鼓励使用设值注入。
   

4. 构造注入能够在构造器中决定依赖关系的注入顺序，优先依赖的优先注入。

5. 对于依赖关系无须变化的Bean，构造注入更有用处，由于没有setter方法，全部的依赖关系所有在构造器内设定，所以，不用担忧后续代码对依赖关系的破坏。

6. 构造注入使依赖关系只能在构造器中设定，则只有组件的建立者才能改变组件的依赖关系。对组件的调用者而言，组件内部的依赖关系彻底透明，更符合高内聚的原则。

7. 设值注入不会重写构造方法的值。若是咱们对同一个变量同时使用了构造方法注入又使用了设置方法注入的话，那么构造方法将不能覆盖由设值方法注入的值。

8. 建议采用以设值注入为主，构造注入为辅的注入策略。对于依赖关系无须变化的注入，尽可能采用构造注入;而其余的依赖关系的注入，则考虑采用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配置文件中的错误，坏处是形成浪费。

这一篇先总结这些，欢迎关注个人公众号“Java知音”，只推送有价值的文章！