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
散布式处理方案
请问你在出产环境中，怎样查找日志的呢？
回答：
- 传统的方式选用tail 查找文件日志，假如服务器是集群的
运用tail 指令查找日志功率是十分低； - 一切咱们构建散布式ELK+Kafka采集日志 ，共同将咱们的日志输出到
ES中，经过可视化界面查询。
3.或许整合skywalking监控服务报警，直接经过skywalking定位服务追寻链
报错信息。
4.在一些较大的互联网企业中，确保服务器端安全性，出产环境一般是不答应直接连接出产环境
服务器，而是经过日志采集体系查看日志。
出产环境中，你遇到了报错的问题 你是怎样定位的？
回答：
- 传统的方式 在出产环境中遇到报错问题，咱们是经过查找日志的方式，排查详细的过错。
2.选用aop方式拦截体系过错日志，在将这些过错日志调用微信大众号接口 主动告知给咱们的开发人员
出产环境产生了故障。 - 咱们公司选用apm体系 skywalking ，监控整个微服务 假如服务在一段时刻
内产生了故障或许报错 会主动调用微信模板接口告诉给开发人员 出产环境产生了故障。在经过skywalking 追寻 链能够直接查看到详细的过错信息内容
调用接口的时分，假如服务器端一向没有及时呼应 怎样处理？
1.假如调用接口产生了呼应推迟：是由于咱们http恳求是选用同步的方式，依据恳求与呼应模型假如服务器端没有及时呼应给客户端，客户端就会认为接口超时，接口产生了超时客户端会不断重试 ，重试的进程中 会导致 幂等性问题
幂等性问题（需求确保事务仅有性。）
2.假如接口呼应十分慢，就需求对代码做优化例如 加上缓存减轻db查询压力、减少GC收回频率
2.假如接口代码在怎样优化 便是履行十分耗时时刻，由于选用mq异步的方式 不能够运用 同步方式。
举例子：接口代码里边 需求调用十分多接口 在呼应客户端
接口代码：
1.调用征信陈述接口—15s-30s
出产环境服务器宕机，怎样处理呢？
- 咱们公司出产环境，会对咱们服务器 完成多个节点集群，假如某台服务器
产生了宕机 会主动完成故障转移，确保服务的高可用。
- 假如服务器宕机 咱们能够在服务器上装置keepalived 监听java进程，假如该java进程产生了宕机 会主动测验重启该java进程，这是归于软件层面。假如是物理机器比方关机了，能够运用硬件方式主动重启服务器 例如向日葵
3.假如服务器产生了宕机，测验重启n屡次仍是失利，咱们能够运用容器快速动态的完成扩容（docker或许k8s）
4.重启该服务，假如重启屡次仍是失利 则会发送短信模板的方式告诉给运维人员。
留意：千万不要回答 直接重启服务器端。
SpringCloud
为什么不挑选dubbo？却挑选SpringCloud？
- dubbo 归于RPC结构；
- SpringCloud 不归于RPC结构，归于微服务全家桶结构，供给十分多
在散布式微服务架构中遇到难题
2.1服务管理—nacos eureka zk
2.2散布式配置中心 nacos springcloud config 携程阿波罗
3.3散布式事务 lcn（被筛选）、seata
3.4服务追寻 zipkin /skwalking
3.5服务维护 hystry、sentinel
3.6微服务网关 zuul gateway
….
feign客户端 rpc结构 类似于 dubbo
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飙高、内存走漏
…….实在事务场景傍边遇到难题
