1. 给定一个二叉搜索树，编写一个函数 kthSmallest 来查找其中第 k 个最小的元素。说明：你可以假设 k 总是有效的，1 ≤ k ≤ 二叉搜索树元素个数。

  • 在面试中常考的树的形状有：
普通二叉树、平衡二叉树、完全二叉树、二叉搜索树、四叉树（Quadtree）、多叉树（N-ary Tree）。

  对于一些特殊的树，例如红黑树（Red-Black Tree）、自平衡二叉搜索树（AVL Tree），一般在面试中不会被问到，除非你所涉及的研究领域跟它们相关或者你十分感兴趣，否则不需要特别着重准备。

  关于树的考题，无非就是要考查树的遍历以及序列化（serialization)。
  所以，这次选定的是“二叉搜索树”。
  • 解题思路
这道题考察了两个知识点：
  1、二叉搜索树的性质
  2、二叉搜索树的遍历

二叉搜索树的性质：对于每个节点来说，该节点的值比左孩子大，比右孩子小，而且一般来说，二叉搜索树里不出现重复的值。

二叉搜索树的中序遍历是高频考察点，节点被遍历到的顺序是按照节点数值大小的顺序排列好的。即，中序遍历当中遇到的元素都是按照从小到大的顺序出现。
因此，我们只需要对这棵树进行中序遍历的操作，当访问到第 k 个元素的时候返回结果就好。

2. 如何手动模拟一个死锁？谈谈你对锁的理解？

  • 回答

死锁是指两个线程同时占用两个资源，又在彼此等待对方释放锁资源，如下图所示：

java禁忌搜索算法 java题搜索_G1

死锁代码演示如下

java禁忌搜索算法 java题搜索_java禁忌搜索算法_02

可以看出当我们使用线程一拥有锁 lock1 的同时试图获取 lock2，而线程二在拥有 lock2 的同时试图获取 lock1，这样就会造成彼此都在等待对方释放资源，于是就形成了死锁。

  • 结论

锁是指在并发编程中，当有多个线程同时操作一个资源时，为了保证数据操作的正确性，我们需要让多线程排队一个一个的操作此资源，而这个过程就是给资源加锁和释放锁的过程，就好像去公共厕所一样，必须一个一个排队使用，并且在使用时需要锁门和开门一样。

3.谈谈Spring中都用到了哪些设计模式？并举例说明。

  • 回答
1.工厂设计模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。

  2.代理设计模式 : Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术。

  3.单例设计模式 : Spring 中的 Bean 默认都是单例的。

  4.模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。

  5.包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。

  6.观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。

  7.适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。

4. MySQL的 binlog 有有几种录入格式？分别有什么区别？

  • 回答

有三种格式，statement，row 和 mixed。

  • 详细
statement 模式下，每一条会修改数据的 SQL 都会记录在 binlog 中。不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。由于 SQL 的执行是有上下文的，因此在保存的时候需要保存相关的信息，同时还有一些使用了函数之类的语句无法被记录复制。

  row 级别下，不记录 SQL 语句上下文相关信息，仅保存哪条记录被修改。记录单元为每一行的改动，基本是可以全部记下来但是由于很多操作，会导致大量行的改动(比如 alter table)，因此这种模式的文件保存的信息太多，日志量太大。

  mixed，一种折中的方案，普通操作使用 statement 记录，当无法使用 statement 的时候使用row 。此外，新版的 MySQL 中对 row 级别也做了一些优化，当表结构发生变化的时候，会记录语句而不是逐行记录。

5. Java常见的垃圾收集器有哪些？

  • 回答

实际上，垃圾收集器（GC，Garbage Collector）是和具体 JVM 实现紧密相关的，不同厂商（IBM、Oracle），不同版本的 JVM，提供的选择也不同。聊聊 5 种最主流的 Oracle JDK。

  • 详细

1、Serial GC，它是最古老的垃圾收集器。
“Serial” 体现在其收集工作是单线程的，并且在进行垃圾收集过程中，会进入臭名昭著的 “Stop-The-World” 状态。当然，其单线程设计也意味着精简的 GC 实现，无需维护复杂的数据结构，初始化也简单，所以一直是 Client 模式下 JVM 的默认选项。
从年代的角度，通常将其老年代实现单独称作 Serial Old，它采用了标记 - 整理（Mark-Compact）算法，区别于新生代的复制算法。Serial GC 的对应 JVM 参数是：

-XX:+UseSerialGC

2、ParNew GC，很明显是个新生代 GC 实现。
它实际是 Serial GC 的多线程版本，最常见的应用场景是配合老年代的 CMS GC 工作，下面是对应参数：

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

3、CMS（Concurrent Mark Sweep） GC，基于标记 - 清除（Mark-Sweep）算法，设计目标是尽量减少停顿时间，这一点对于 Web 等反应时间敏感的应用非常重要。
一直到今天，仍然有很多系统使用 CMS GC。但是，CMS 采用的标记 - 清除算法，存在着内存碎片化问题，所以难以避免在长时间运行等情况下发生 full GC，导致恶劣的停顿。另外，既然强调了并发（Concurrent），CMS 会占用更多 CPU 资源，并和用户线程争抢。

4、Parallel GC，在早期 JDK 8 等版本中，它是 server 模式 JVM 的默认 GC 选择，也被称作是吞吐量优先的 GC。
它的算法和 Serial GC 比较相似，尽管实现要复杂的多，其特点是新生代和老年代 GC 都是并行进行的，在常见的服务器环境中更加高效。开启选项是：

-XX:+UseParallelGC

另外，Parallel GC 引入了开发者友好的配置项，我们可以直接设置暂停时间或吞吐量等目标，JVM 会自动进行适应性调整，例如下面参数：

-XX:MaxGCPauseMillis=value

-XX:GCTimeRatio=N // GC时间和用户比例 = 1 （N+1）

5、G1 GC 这是一种兼顾吞吐量和停顿时间的 GC 实现，是 Oracle JDK 9 以后的默认 GC 选项。
G1 可以直观的设定停顿时间的目标，相比于 CMS GC，G1 未必能做到 CMS 在最好情况下的延时停顿，但是最差情况要好很多。

G1 GC 仍然存在着年代的概念，但是其内存结构并不是简单的条带式划分，而是类似棋盘的一个个 region。Region 之间是复制算法，但整体上实际可看作是标记 - 整理（Mark-Compact）算法，可以有效地避免内存碎片，尤其是当 Java 堆非常大的时候，G1 的优势更加明显。
G1 吞吐量和停顿表现都非常不错，并且仍然在不断地完善，与此同时 CMS 已经在 JDK 9 中被标记为废弃（deprecated），所以 G1 GC 值得你深入掌握。