哈啰出行面经

1、序列化
Java 对象实现序列化要实现 Serializable 接口。

反序列化并不会调用构造方法。反序列的对象是由 JVM 自己生成的对象，不通过构造方法生成。
序列化对象的引用类型成员变量，也必须是可序列化的，否则，会报错。
如果想让某个变量不被序列化，使用 transient 修饰。
单例类序列化，需要重写 readResolve() 方法。

2、
HashMap (1.7) 多线程循环链表问题
在多线程环境下，进行扩容时，1.7 下的 HashMap 会形成循环链表。
怎么形成循环链表： 假设有一 HashMap 容量为 2 ， 在数组下标 1 位置以 A -> B 链表形式存储。有一线程对该 map 做 put 操作，由于触发扩容条件，需要进行扩容。这时另一个线程也 put 操作，同样需要扩容，并完成了扩容操作，由于复制到新数组是头部插入，所以 1 位置变为 B -> A 。这时第一个线程继续做扩容操作，首先复制 A ，然后复制 B ，再判断 B.next 是否为空时，由于第二个线程做了扩容操作，导致 B.next = A，所以在将 A 放到 B 前，A.next 又等于 B ，导致循环链表出现。
3、synchronized
修饰代码块 底层实现，通过 monitorenter & monitorexit 标志代码块为同步代码块。
修饰方法 底层实现，通过 ACC_SYNCHRONIZED 标志方法是同步方法。
修饰类 class 对象时，实际锁在类的实例上面。
偏向锁，自旋锁，轻量级锁，重量级锁
通过 synchronized 加锁，第一个线程获取的锁为偏向锁，这时有其他线程参与锁竞争，升级为轻量级锁，其他线程通过循环的方式尝试获得锁，称自旋锁。若果自旋的次数达到一定的阈值，则升级为重量级锁。
需要注意的是，在第二个线程获取锁时，会先判断第一个线程是否仍然存活，如果不存活，不会升级为轻量级锁。

4、volatile
在多线程环境下，保证变量的可见性。使用了 volatile 修饰变量后，在变量修改后会立即同步到主存中，每次用这个变量前会从主存刷新。
禁止 JVM 指令重排序。
单例模式双重校验锁变量为什么使用 volatile 修饰？ 禁止 JVM 指令重排序，new Object()分为三个步骤：申请内存空间，将内存空间引用赋值给变量，变量初始化。如果不禁止重排序，有可能得到一个未经初始化的变量。
5、Runnable 和 Callable 比较
方法签名不同， void Runnable.run() , V Callable.call() throws Exception
是否允许有返回值， Callable 允许有返回值
是否允许抛出异常， Callable 允许抛出异常。
提交任务方式， Callable 使用 Future submit(Callable task) 返回 Future 对象，调用其 get() 方法可以获得返回值， Runnable 使用 void execute(Runnable command) 。
6、
ThreadLocal
场景 主要用途是为了保持线程自身对象和避免参数传递，主要适用场景是按线程多实例（每个线程对应一个实例）的对象的访问，并且这个对象很多地方都要用到。
原理 为每个线程创建变量副本，不同线程之间不可见，保证线程安全。使用 ThreadLocalMap 存储变量副本，以 ThreadLocal 为 K，这样一个线程可以拥有多个 ThreadLocal 对象。
实际 使用多数据源时，需要根据数据源的名字切换数据源，假设一个线程设置了一个数据源，这个时候就有可能有另一个线程去修改数据源，可以使用 ThreadLocal 维护这个数据源名字，使每个线程持有数据源名字的副本，避免线程安全问题。
7、Java 类加载机制
• 加载 加载字节码文件。
• 链接
○ 验证 验证字节码文件的正确性。
○ 准备 为静态变量分配内存。
○ 解析 将符号引用（如类的全限定名）解析为直接引用（类在实际内存中的地址）。
• 初始化 为静态变量赋初值。
• 双亲委派模式
当一个类需要加载时，判断当前类是否被加载过。已经被加载的类会直接返回，否则才会尝试加载。加载的时候，首先会把该请求委派该父类加载器的 loadClass() 处理，因此所有的请求最终都应该传送到顶层的启动类加载器 BootstrapClassLoader 中。当父类加载器无法处理时，才由自己来处理。当父类加载器为 null 时，会使用启动类加载器 BootstrapClassLoader 作为父类加载器。
8、为何使用 B 树做索引而不是红黑树？
索引很大，通常作为文件存储在磁盘上面，每次检索索引都需要把索引文件加载进内存，所以磁盘 IO 的次数是衡量索引数据结构好坏的重要指标。应用程序在从磁盘读取数据时，不只是读取需要的数据，还会连同其他数据以页的形式做预读来减少磁盘 IO 的次数。数据库的设计者将每个节点的大小设置为一页的大小，同时每次新建节点时都重新申请一个页，这样检索一个节点只需要一次 IO，根据索引定位到数据只需要 h- 1（h 为 B 树高度，根节点常驻内存） 次 IO，而 d (度，可以理解为宽度)与 h 称反比，即 d 越大，高度就越小，所以树越扁，磁盘 IO 次数越少，即渐进复杂度为 logdN ，这也是为什么不选择红黑树做索引的原因。前面可以得出结论，d 越大，索引的性能越好。节点由 key 和 data 组成，页的大小一定，key 和 data 越小，d 越大。B + 树去掉了节点内的 data 域，所以有更大的 d , 性能更好。

9、Bean 生命周期
简单来说四步：

实例化 Instantiation
属性赋值 Populate
初始化 Initialization
销毁 Destruction
在这四步的基础上面，Spring 提供了一些拓展点：

Bean 自身的方法: 这个包括了 Bean 本身调用的方法和通过配置文件中 %3Cbean %3E 的 init-method 和 destroy-method 指定的方法
Bean 级生命周期接口方法: 这个包括了 BeanNameAware、BeanFactoryAware、InitializingBean 和 DiposableBean 这些接口的方法
容器级生命周期接口方法：这个包括了 InstantiationAwareBeanPostProcessor 和 BeanPostProcessor 这两个接口实现，一般称它们的实现类为“后处理器”。
工厂后处理器接口方法: 这个包括了 AspectJWeavingEnabler, ConfigurationClassPostProcessor, CustomAutowireConfigurer 等等非常有用的工厂后处理器接口的方法。工厂后处理器也是容器级的。在应用上下文装配配置文件之后立即调用。

10、如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
消息过期失效问题，如果消息一段时间不消费，导致过期失效了，消息就丢失了，只能重新查出丢失的消息，重新发送。 再来说消息积压的问题：（思路是快速消费掉积压的消息）

首先排查消费端问题，恢复消费端正常消费速度。
然后着手处理队列中的积压消息。
停掉现有的 consumer。
新建一个 topic ，设置之前 10 倍的 partation，之前 10 倍的队列。
写一个分发程序，将积压的消息均匀的轮询写入这些队列。
然后临时用 10 倍的机器部署 consumer，每一批 consumer 消费 1 个临时的队列。
消费完毕后，恢复原有架构。
消息队列满了：只能边接收边丢弃，然后重新补回丢失的消息，再继续消费
11、LRU算法
LRU算法最为精典的实现，就是HashMap+Double LinkedList，时间复杂度为O(1)
Redis中采用两种算法进行内存回收，引用计数算法以及LRU算法
引用计数算法
REDIS中LRU算法的实际应用,在Redis 1.0中并未引入LRU算法，只是简单的使用引用计数法，去掉内存中不再引用的对象以及运行一个定时任务serverCron去掉内存中已经过期的对象占用的内存空间,以下是Redis 1.0中CT任务的释放内存中的部份代码
LRU算法 配置文件在redis.conf文件中,如下所示
从上面的配置中，可以看出,高版本的Redis中当内存达到极限时，内存淘汰策略主要采用了6种方式进行内存对象的释放操作
1.volatile-lru:从设置了过期时间的数据集中，选择最近最久未使用的数据释放
2.allkeys-lru:从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，选择最近最久未使用的数据释放
3.volatile-random:从设置了过期时间的数据集中，随机选择一个数据进行释放
4.allkeys-random:从数据集中(包括了设置过期时间以及未设置过期时间)随机选择一个数据进行入释放
5.volatile-ttl：从设置了过期时间的数据集中，选择马上就要过期的数据进行释放操作
6.noeviction：不删除任意数据(但redis还会根据引用计数器进行释放呦~),这时如果内存不够时，会直接返回错误
默认的内存策略是noeviction，在Redis中LRU算法是一个近似算法，默认情况下，Redis随机挑选5个键，并且从中选取一个最近最久未使用的key进行淘汰，在配置文件中可以通过maxmemory-samples的值来设置redis需要检查key的个数,但是栓查的越多，耗费的时间也就越久,但是结构越精确(也就是Redis从内存中淘汰的对象未使用的时间也就越久_{),设置多少，综合权衡吧}~~

12、hashmap怎么解决hash冲突的
hashmap出现了Hash冲突的时候采用第二种办法：链地址法。
1).每当往hashmap里面存放key-value对的时候，都会为它们实例化一个Entry对象，这个Entry对象就会存储在前面提到的Entry数　　组table中。现在你一定很想知道，上面创建的Entry对象将会存放在具体哪个位置（在table中的精确位置）。答案就是，根据key的　　　　　hashcode()方法计算出来的hash值（来决定）。hash值用来计算key在Entry数组的索引。
2).现在，如果你看下上图中数组的索引15，它有一个叫做HashMap$Entry的Entry对象。
3).我们往hashmap放了4个key-value对，但是看上去好像只有1个元素！！！这是因为，如果两个元素有相同的hashcode，它们会　　被放在同一个索引上。问题出现了，该怎么放呢？原来它是以链表(LinkedList)的形式来存储的(逻辑上)。因此他们都在hash值为15的位置　　上存着了，然后把多个Entry，用next进行链接。
减少hash冲突？扰动函数可以减少碰撞
原理是如果两个不相等的对象返回不同的 hashcode 的话，那么碰撞的几率就会小些。这就意味着存链表结构减小，这样取值的话就不会频繁调用 equal 方法，从而提高 HashMap 的性能（扰动即 Hash 方法内部的算法实现，目的是让不同对象返回不同hashcode）。
使用不可变的、声明作 final 对象，并且采用合适的 equals() 和 hashCode() 方法，将会减少碰撞的发生不可变性使得能够缓存不同键的 hashcode，这将提高整个获取对象的速度，使用 String、Integer 这样的 wrapper 类作为键是非常好的选择。
为什么 String、Integer 这样的 wrapper 类适合作为键？

因为 String 是 final，而且已经重写了 equals() 和 hashCode() 方法了。不可变性是必要的，因为为了要计算 hashCode()，就要防止键值改变，如果键值在放入时和获取时返回不同的 hashcode 的话，那么就不能从 HashMap 中找到你想要的对象。
13、
Dubbo 大数据包问题
14、Spring 如何解决循环依赖？
1、出现循环依赖的Bean必须要是单例
2、依赖注入的方式不能全是构造器注入的方式

依赖情况 依赖注入方式 循环依赖是否被解决
AB相互依赖（循环依赖） 均采用setter方法注入 是
AB相互依赖（循环依赖） 均采用构造器注入 否
AB相互依赖（循环依赖） A中注入B的方式为setter方法，B中注入A的方式为构造器 是
AB相互依赖（循环依赖） B中注入A的方式为setter方法，A中注入B的方式为构造器 否

1. singletonObjects，一级缓存，存储的是所有创建好了的单例Bean
2. earlySingletonObjects，完成实例化，但是还未进行属性注入及初始化的对象
3. singletonFactories，提前暴露的一个单例工厂，二级缓存中存储的就是从这个工厂中获取到的对象
4. https://www.cnblogs.com/daimzh/p/13256413.html
   面试官：”Spring是如何解决的循环依赖？“
   答：Spring通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects）,二级缓存为早期曝光对象earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。当A、B两个类发生循环引用时，在A完成实例化后，就使用实例化后的对象去创建一个对象工厂，并添加到三级缓存中，如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象。当A进行属性注入时，会去创建B，同时B又依赖了A，所以创建B的同时又会去调用getBean(a)来获取需要的依赖，此时的getBean(a)会从缓存中获取，第一步，先获取到三级缓存中的工厂；第二步，调用对象工工厂的getObject方法来获取到对应的对象，得到这个对象后将其注入到B中。紧接着B会走完它的生命周期流程，包括初始化、后置处理器等。当B创建完后，会将B再注入到A中，此时A再完成它的整个生命周期。至此，循环依赖结束！
   面试官：”为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？“
   答：如果要使用二级缓存解决循环依赖，意味着所有Bean在实例化后就要完成AOP代理，这样违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。
   为什么在下表中的第三种情况的循环依赖能被解决，而第四种情况不能被解决呢？
   提示：Spring在创建Bean时默认会根据自然排序进行创建，所以A会先于B进行创建
   依赖情况 依赖注入方式 循环依赖是否被解决
   AB相互依赖（循环依赖） 均采用setter方法注入 是
   AB相互依赖（循环依赖） 均采用构造器注入 否
   AB相互依赖（循环依赖） A中注入B的方式为setter方法，B中注入A的方式为构造器 是
   AB相互依赖（循环依赖） B中注入A的方式为setter方法，A中注入B的方式为构造器 否
   15、线程池动态更新
   setCorePoolSize
   在运行期线程池使用方调用此方法设置corePoolSize之后，线程池会直接覆盖原来的corePoolSize值，并且基于当前值和原始值的比较结果采取不同的处理策略。
   对于当前值小于当前工作线程数的情况，说明有多余的worker线程，此时会向当前idle的worker线程发起中断请求以实现回收，多余的worker在下次idel的时候也会被回收；
   对于当前值大于原始值且当前队列中有待执行任务，则线程池会创建新的worker线程来执行队列任务
   setMaximumPoolSize
   1.首先是参数合法性校验。
   2.然后用传递进来的值，覆盖原来的值。
   3.判断工作线程是否是大于最大线程数，如果大于，则对空闲线程发起中断请求。

调整的时候可能会出现核心线程数调整之后无效的情况
创建新的工作线程 worker，然后工作线程数进行加一操作。 运行创建的工作线程 worker，开始获取任务 task。 工作线程数量大于最大线程数，对工作线程数进行减一操作。 返回 null，即没有获取到 task。 清理该任务，流程结束。
创建新的工作线程 worker，然后工作线程数进行加一操作。 运行创建的工作线程 worker，开始获取任务 task。 工作线程数量大于最大线程数，对工作线程数进行减一操作。 返回 null，即没有获取到 task。 清理该任务，流程结束。
当 allowCoreThreadTimeOut 参数设置为 true 的时候，核心线程在空闲了 keepAliveTime 的时间后也会被回收的，相当于线程池自动给你动态修改了。

如何动态指定队列长度？
因为队列的 capacity 是被 final 修饰了呀。没有提供队列长度的 set 方法
操作起来也非常方便，把 LinkedBlockingQueue 粘贴一份出来，修改个名字，然后把 Capacity 参数的 final 修饰符去掉，并提供其对应的 get/set 方法。
然后在程序里面把原来的队列换掉：

线程池被创建后里面有线程吗？如果没有的话，你知道有什么方法对线程池进行预热吗？
线程池被创建后如果没有任务过来，里面是不会有线程的。如果需要预热的话可以调用下面的两个方法：

七只老鼠，一百瓶药水，其中有一瓶是毒药，毒发时间为一天，使用一天时间检测出毒药
对100瓶毒药进行二进制编码，0000001，0000010，…，1100100

老鼠分别为A,B,C,D,E,F,G

A老鼠喝编码格式为1xxxxxx的药水

B老鼠喝编码格式为x1xxxxx的药水

C老鼠喝编码格式为xx1xxxx的药水

D老鼠喝编码格式为xxx1xxx的药水

E老鼠喝编码格式为xxxx1xx的药水

F老鼠喝编码格式为xxxxx1x的药水

G老鼠喝编码格式为xxxxxx1的药水

最后查看老鼠死亡情况，假如E和F死亡，说明0000110为毒药。