我目前是一名大数据开发工程师，曾经是一名高级Java工程师，我总结我在面试过程中的一些知识和经验，还有遇到的问题，希望对正在面试求职的你有一些帮助。这篇文章有题目有答案，没有完整答案的题目也会提供给你思路。

问题1：kafka跟磁盘交互，快速的原因。

**顺序写磁盘**

在我们的生产环境中，为了节约成本，大部分服务器仍然使用机械磁盘，而非固态硬盘。我们知道，机械磁盘读写数据，首先需要寻道，将磁头调整到对应的磁道上，紧接着，会进行旋转，将磁头旋转到对应的位置上，最后才是读写数据，寻道跟旋转，占用了磁盘读写的大量时间，所以，Apache Kafka在写磁盘的时候，大量的使用了追加写的模式，减少了磁盘寻道与旋转地时间，从而达到更高的磁盘利用率。

**大量使用内存页**

我们知道，即便是顺序写磁盘，磁盘的读写速度仍然比内存慢慢的多得多，好在操作系统已经帮我们解决这个问题了，在Linux操作系统中，Linux会将磁盘中的一些数据读取到内存当中，我们称之为内存页。当需要读写硬盘的时候，都优先在内存页中进行处理。读的话大家比较好理解，就是缓存嘛，写的话如果只写在缓存没有落盘不是会形成脏数据么?的确如此，只有当网页到达一定比例之后，Linux操作系统才会把数据刷到磁盘当中。在机器发生掉电的时候，的确会出现脏数据。但是，我们更应该使用分布式写到多台机器上来从根本上解决这个问题。

并且，写在内存页的另外一个好处是减少应用内存的使用，我们都知道Apache Kafka是用Java语言编写的，不得不避免的便是Java的GC问题，随着应用内存的增多，垃圾回收的时间会更多，带来整体性能的下降。

**零拷贝技术的使用**

作为一个消息系统，不可避免的便是消息的拷贝，常规的操作，一条消息，需要从创建者的socket到应用，再到操作系统内核，然后才能落盘。同样，一条消息发送给消费者也要从磁盘到内核到应用再到接受者的socket，中间经过了多次不是很有必要的拷贝。

在Linux操作系统中，同样为我们提供了零拷贝技术，零拷贝技术并非真的不用拷贝，而是大大地减少了拷贝次数。举个例子，原本从磁盘到接收者Socket中，需要见过内核态，又要经过Apache Kafka应用，那么有没有可能直接越过这两层状态，达到更少的拷贝次数呢?Java 的NIO库，帮我们实现了这一切，借用JavaNIO库封装的API，我们可以直接使用Linux操作系统的零拷贝技术，让系统更快。

**分区分段**

partition和segment

问题二：TCP的拥塞控制

“慢启动”（Slow Start）、“拥塞避免”（Congestion voidance）、“快速重传 ”（Fast Retransmit）、“快速恢复”（Fast Recovery）。

慢开始算法##

当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

慢开始的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段（目的是试探一下网络的拥塞情况），然后再指数增大cwnd。

拥塞避免算法

让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

快速重传和快速恢复

重复确认： 发送端有一个方法可以快速确认发送端是不是出错了，当丢失的数据包的后续数据包到达接收端时候，他们触发给发送端返回确认。这些确认号都是一样的，叫做重复确认。

快速重传 当发生三次重复确认，即使没有超时，也会重传，叫做快速重传。重传完毕，阀值减半，就像发生超时一样，慢启动开始，到了阀值，再线性增长。

快速恢复 快速重传后，拥塞窗口被设置到慢启动的阀值，开始线性增长。

问题三：MYSQL 两个索引字段是否生效

不生效

问题四：Mysql的 innodb 行锁原理

InnoDB行锁是通过给索引上的索引项加锁来实现的，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁

InnoDB是通过搜索或者扫描表中索引来完成加锁操作，InnoDB会为他遇到的每一个索引数据加上共享锁或排他锁。所以我们可以称行级锁（row-level locks）为索引记录锁（index-record locks），因为行级锁是添加到行对应的索引上的。

InnoDB的行级锁定同样分为两种类型，共享锁和排他锁

当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。

问题五：判断链表是否有环

可以采用“快慢指针”的方法。就是有两个指针fast和slow，开始的时候两个指针都指向链表头head，然后在每一步

操作中slow向前走一步即：slow = slow->next，而fast每一步向前两步即：fast = fast->next->next。

问题六：redis

对于“Redis挂掉了，请求全部走数据库”这种情况，我们可以有以下的思路：

• 事发前：实现Redis的高可用(主从架构+Sentinel 或者Redis Cluster)，尽量避免Redis挂掉这种情况发生。
• 事发中：万一Redis真的挂了，我们可以设置本地缓存(ehcache)+限流(hystrix)，尽量避免我们的数据库被干掉(起码能保证我们的服务还是能正常工作的)
• 事发后：redis持久化，重启后自动从磁盘上加载数据，快速恢复缓存数据。
• 解决方法：在缓存的时候给过期时间加上一个随机值，这样就会大幅度地减少缓存在同一时间过期。

缓存穿透：

解决缓存穿透也有两种方案：

- 由于请求的参数是不合法的(每次都请求不存在的参数)，于是我们可以使用布隆过滤器(BloomFilter)或者压缩filter**提前拦截**，不合法就不让这个请求到数据库层！

**布隆过滤器会隔一段时间扫描一次缓存和数据库，会将缓存和数据库共有的数据添加到布隆过滤器，当由请求过来时，会先进入布隆过滤器中进行查找，有的话返回数据，没有的话会到数据中查找**

- 当我们从数据库找不到的时候，我们也将这个

空对象设置到缓存里边去

。下次再请求的时候，就可以从缓存里边获取了。

- 这种情况我们一般会将空对象设置一个**较短的过期时间**。

缓存击穿：

**缓存击穿：意思是缓存当中没有，而数据库有的数据，如果有98次请求的话，就会查询98次数据库，出现的了是并发问题。

原因：缓存中没有这个数据或者是这个数据刚刚达到过期时间失效了。

解决方法：添加分布式锁** 如果我们有98次请求去查找这个key，当我们redisLock.lock(key)，开启分布式锁时，98次请求就会只进去一次请求，只有一个线程执行，查询缓存，如果缓存没有的话去数据库查找，然后给缓存添加数据，最后解锁，然后就会再进去一次请求，还是只有一个线程执行，此时缓存中已经有数据了，这个线程就会到缓存中去查找，后续的都一样，所以就会执行一次查询数据的方法，这样就解决了缓存穿透这个问题。

#### 什么是缓存与数据库双写一致问题？

从理论上说，只要我们设置了**键的过期时间**，我们就能保证缓存和数据库的数据**最终是一致**的。因为只要缓存数据过期了，就会被删除。随后读的时候，因为缓存里没有，就可以查数据库的数据，然后将数据库查出来的数据写入到缓存中。

除了设置过期时间，我们还需要做更多的措施来**尽量避免**数据库与缓存处于不一致的情况发生。

**分布式事务**的问 题。

### 3.3.1操作缓存

操作缓存也有两种方案：

- 更新缓存

- 删除缓存

一般我们都是采取**删除缓存**缓存策略的，原因如下：

1. 高并发环境下，无论是先操作数据库还是后操作数据库而言，如果加上更新缓存，那就**更加容易**导致数据库与缓存数据不一致问题。(删除缓存**直接和简单**很多)

2. 如果每次更新了数据库，都要更新缓存【这里指的是频繁更新的场景，这会耗费一定的性能】，倒不如直接删除掉。等再次读取时，缓存里没有，那我到数据库找，在数据库找到再写到缓存里边(体现**懒加载**)

基于这两点，对于缓存在更新时而言，都是建议执行**删除**操作！

问题六：Actomic原理

unsafe是java提供的获得对对象内存地址访问的类，注释已经清楚地写出了，它的作用就是在更新操作时提供“比较并替换”的作用 。

如何保证原子性：自旋 + CAS（乐观锁）。在这个过程中，通过compareAndSwapInt比较更新value值，如果更新失败，重新获取旧值，然后更新 。

通过CAS乐观锁保证原子性，通过自旋保证当次修改的最终修改成功，通过降低锁粒度（多段锁）增加并发性能。

问题七：Int，char，varchar类型区别

varchar Varchar往往用来保存可变长度的字符串。简单的说，我们只是给其固定了一个最大值，然后系统会根据实际存储的数据量来分配合适的存储空间 .

CHAR数据类型与VARCHAR数据类型不同，其采用的是固定长度的存储方式。简单的说，就是系统总为其分配最大的存储空间 显然，这种存储方式会造成磁盘空间的浪费 .

经常需要修改而容易形成碎片 , 十分频繁改变的column。因为varchar每次存储都要有额外的计算，得到长度等工作，如果一个非常频繁改变的，那就要有很多的精力用于计算，而这些对于char来说是不需要的

问题八：从年轻代转移到老年代

1.通过年龄计数器判断一个对象是否需要转移。 1.通过年龄计数器判断一个对象是否需要转移。对象每经过一个GC仍然存活，年龄计数器加一。当年龄超过设定的值，则将其通过担保机制转移到老年代。

2.或者动态绑定，当Suvivor中年龄相同的对象数量超过一半，则年龄大于等于该年龄的的对象转移到老年代，无需等待设置的最大年龄值。

3.大对象直接进入老年代。

问题九：spring的单例多线程问题

Spring使用ThreadLocal解决线程安全问题

我们知道在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声明为singleton作用域。就是因为Spring对一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非线程安全状态采用ThreadLocal进行处理，让它们也成为线程安全的状态，因为有状态的Bean就可以在多线程中共享了。 ThreadLocal是解决线程安全问题一个很好的思路，它通过为每个线程提供一个独立的变量副本解决了变量并发访问的冲突问题。在很多情况下，ThreadLocal比直接使用synchronized同步机制解决线程安全问题更简单，更方便，且结果程序拥有更高的并发性。

问题十：https访问页面的全过程

问题十一：MYSQL主从复制原理

步骤一：主库db的更新事件(update、insert、delete)被写到binlog 步骤二：从库发起连接，连接到主库 步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log. 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

问题十二：MYBatis 一级缓存和二级缓存

Sqoop在import时，需要制定split-by参数。Sqoop根据不同的split-by参数值来进行切分,然后将切分出来的区域分配到不同map中。

每个map中在处理数据库中获取的一行一行的值，写入到HDFS中。同时split-by根据不同的参数类型有不同的切分方法，如比较简单的int型，

Sqoop会取最大和最小split-by字段值，然后根据传入的num-mappers来确定划分几个区域。 比如select max(split_by),min(split-by) from

得到的max(split-by)和min(split-by)分别为1000和1，而num-mappers为2的话，则会分成两个区域(1,500)和(501-100),

同时也会分成2个sql给2个map去进行导入操作，分别为select XXX from table where split-by>=1 and split-by<500和

select XXX from table where split-by>=501 and split-by<=1000。最后每个map各自获取各自SQL中的数据进行导入工作。

问题十三：Scala和Java区别？

问题十四：java NoSuchMethod异常解决方法？