谈一谈对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）
垃圾回收算法：
引用计数法
标记清除法
复制算法
标记压缩算法
分代算法
分区算法
以上这些，可以自己了解一下，这里列举几篇相关文章：
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中依赖注入两种方式的认识
两种注入方式为：构造方法注入和设值注入
设值注入与传统的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配置文件中的错误，坏处是造成浪费。
这一篇先总结这些，欢迎关注我的公众号“Java知音”，只推送有价值的文章！