2023年新的一份Java面试中的葵花宝典敬请收下，解决你的面试困扰

HashMap面试题 HashMap与HashTable的区别

1.HashMap线程不安全 HashTable 线程是安全的选用synchronized 2.HashMap答应寄存key 为null HashTable 不答应寄存key 为null 3.在多线程的情况下，引荐运用ConcurrentHashMap 线程安全 且功率十分高

HashMap底层是怎样完成的

在HashMap1.7版别中底层是依据数组+链表完成的，假如产生Hash抵触概率 比较大，会寄存到同一个链表中，链表假如过长 会从头查询到尾部 功率十分低。 所以在HashMap1.8版别 （数组容量>=64&链表长度大于8） 就会将该链表转化红黑树。 HashMap依据Key查询时刻复杂度？

1.Key没有产生抵触 时刻复杂度是为o(1); 只需求查询一次 2.Key产生抵触 选用链表寄存则为O(N) 从头查询到尾部 3.key产生抵触选用红黑树寄存则为O（LogN） HashMap底层是有序寄存的吗？

是无序的，由于Hash 算法是散列核算的 没有顺序，假如需求顺序 能够运用LinkedHashMap集合选用双向链表寄存。

HashMap7扩容发存亡循环问题有了解过吗？ 其实这个JDK官方不承认这个bug，由于HashMap自身是线程不安全的，不引荐在 多线程的情况下运用，是前期阿里一名职工 产生在多线程 的情况下运用HashMap1.7 扩容会发存亡循环问题，由于HashMap1.7 选用头插入法 后来在在HashMap1.8 改为尾插法 。 假如是在多线程的情况下 引荐运用ConcurrentHashMap

HashMap Key 为null 寄存在 什么位置 寄存在数组 index为0的位置。 ConcurrentHashMap 底层是怎样完成？ 1.传统方式 运用HashTable确保线程问题，是选用synchronized锁将整个HashTable中的数组锁住， 在多个线程中只答应一个线程拜访Put或许Get，功率十分低，但是能够确保线程安全问题。 2.多线程的情况下 JDK官方引荐运用ConcurrentHashMap ConcurrentHashMap 1.7 选用分段锁规划 底层完成原理：数组+Segments分段锁+HashEntry链表完成 大致原理便是将一个大的HashMap 分成n多个不同的小的HashTable 不同的key 核算index 假如没有产生抵触 则寄存到不同的小的HashTable中 ，从而能够完成多线程 一起做put操作，但是假如多个线程一起put操作 key 产生了index抵触落到同一个小的HashTable中 仍是会产生竞赛锁。 3.ConcurrentHashMap 1.7 选用 Lock锁+CAS乐观锁+UNSAFE类 里边有完成 类似于synchronized 锁的升级进程。 4.ConcurrentHashMap 1.8版别 put操作 撤销segment分段规划 直接运用Node数组来保存数据 index没有产生抵触运用cas锁 index 假如产生抵触则 运用 synchronized

散布式处理方案

请问你在出产环境中，怎样查找日志的呢？ 回答：

出产环境中，你遇到了报错的问题 你是怎样定位的？ 回答：

调用接口的时分，假如服务器端一向没有及时呼应 怎样处理？

1.假如调用接口产生了呼应推迟：是由于咱们http恳求是选用同步的方式，依据恳求与呼应模型假如服务器端没有及时呼应给客户端，客户端就会认为接口超时，接口产生了超时客户端会不断重试 ，重试的进程中 会导致 幂等性问题 幂等性问题（需求确保事务仅有性。） 2.假如接口呼应十分慢，就需求对代码做优化例如 加上缓存减轻db查询压力、减少GC收回频率 2.假如接口代码在怎样优化 便是履行十分耗时时刻，由于选用mq异步的方式 不能够运用 同步方式。 举例子：接口代码里边 需求调用十分多接口 在呼应客户端 接口代码： 1.调用征信陈述接口—15s-30s

出产环境服务器宕机，怎样处理呢？

SpringCloud 为什么不挑选dubbo？却挑选SpringCloud？

dubbo rpc结构 底层 netty 封装dubbo 协议 整合散布式处理方案—自己独自整合 单一功能 而springcloud 供给了老练一套微服务处理方案。 dubbox 归于当当网供给 http协议接口 feign 调用接口 http协议 开放渠道（阿里、腾讯） http协议 跨渠道

dubbo与feign 都是面向接口 调用 底层思想原理都是相同。 底层选用动态署理技术。 服务正在发布中？怎样不影响用户运用？

服务正在发布中，该jar中正在发动… 客户端拜访的时分，一向阻塞等候。 1.运用nginx 故障转移即可。 2.灰度发布 先发布一小部分 假如没有问题 在让一切用户都能够拜访。 灰度发布 nginx+nacos gateway+nacos（引荐） 对方调用你接口呼应比较慢？你会怎样排查？ 项目建立服务追寻监控体系 1.zipkin /skwalking 经过渠道方式能够查询该接口呼应速度时刻。 对方调用你接口呼应比较慢 多个维度思考？ 带宽→服务处理（cpu）→数据库或许Redis→网络IO操作（例如调用他人接口） 1.走外网传输数据 会有带宽限制呢 2.恳求假如到达服务端，服务满足线程处理恳求 假如服务器没有满足的线程 处理该恳求？ 导致客户端会阻塞等候？ 处理办法: 1.调整最大线程数 2.调整最大线程数 治标不治本，对接口做限流操作 例如服务器端没有满足 线程处理的时分（战略服务熔断 降级 限流战略。） 3.服务cpu处理性能（多核cpu） 表现多线程一起处理 降低cpu上下文切换的次数。 假如产生了上下文切换会导致其他的线程 会时间短阻塞 有需求从新被cpu调度。 4.判断sql语句查询是否比较慢、做mysql调优 快速呼应成果 5.网络IO操作（例如调用他人接口）代码在怎样优化仍是比较慢，将耗时的操作 选用异步的方式处理 例如多线程（消耗cpu的资源） 主张运用MQ。

开发者不小心删去了出产环境数据？怎样康复呢？ 1.正常的情况下 在出产环境中 没有delete或许rm -rf 经过update 隐藏的方式， 后期筛选战略删去。 2.构建mysql主从集群环境 能够经过备份节点康复数据，一主一从。 3.假如履行delete 咱们是能够经过binlog 快速康复数据。

你在开发进程中，遇到哪些难题？你是怎样处理的呢

假如在面试的进程中被面试官问到：你在开发进程中，遇到哪些难题？ 不要答：空指针异常、常见过错异常。 遇到问题→你是怎样分析的？→怎样排查的？→终究是怎样处理的？ 1.散布式事务 2.散布式幂等 例如 咱们公司供给了一个接口，被其他公司进行调用。 他的公司在调用咱们公司接口的进程中，咱们的接口呼应超时了， 终究触发了客户端重试了，重试的进程傍边恳求的参数都是相同的，导致咱们接口 会重复履行事务逻辑。 处理办法： 全局id 事务上防重复、 在db层面去重复 例如 创建仅有约束 3.守时使命调度 例如：咱们项目在出产环境中做守时使命，假如集群的情况下 守时使命重复履行。 处理该问题 1.在打jar包的时分 加上一个开关 只让一个jar包履行守时使命 2.整合散布式使命调度渠道 xxljob 终究分片履行 守时使命集群的履行 守时使命1 【】跑批 1-10万 守时使命2 11-20万 4.数据同步推迟问题 咱们公司 运用canal 处理mysql与redis+kafka 数据同步问题 发现便是在并发的情况下同步十分推迟，咱们整合kafka分区模型 依据每张表都有自己独立的topic主题，每个topic 主题有自己独立 分区 每个分区有自己独立顾客 ，处理音讯顺序共同性问题。

6.安全性问题 7出产环境产生cpu飙高、内存走漏 …….实在事务场景傍边遇到难题