阿里面试题库

阿里面试题

•SpringBoot

•什么是SpringBoot?

SpringBoot是Spring开源组织下的子项目，是Spring组件一站式解决方案，主要是简化了使

用Spring的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。

•为什么要用SpringBoot?

SpringBoot优点非常多，如：独立运行简化配置自动配置无代码生成和XML配置应用监控

上手容易

・Springboot启动方式

•SpringBoot的核心配置文件有哪几个？它们的区别是什么？

SpringBoot的核心配置文件是application和bootstrap配置文件。application配置文件这个

主要用于SpringBoot项目的自动化配置。bootstrap配置文件有以下几个应用场景。使用

SpringCloudConfig配置中心时，这时需要在bootstrap配置文件中添加连接到配置中心的配置

属性来加载外部配置中心的配置信息；一些固定的不能被覆盖的属性；一些加密/解密的场景；

・SpringBoot的配置文件有哪几种格式？它们有什么区别？

.properties和.yml,它们的区别主要是书写格式不同。1).properties=javastack

2),ymlapp:user:name:javastack另夕卜，.yml格式不支持@PropertySource注解导入配置。

•你如彳可理解SpringBoot中的Starters?

Starters可以理解为启动器，它包含了一系列可以集成到应用里面的依赖包，你可以一站式集成

Spring及其他技术，而不需要到处找示例代码和依赖包。如你想使用SpringJPA访问数据库，

只要加入spring-boot-starter-data-jpa启动器依赖就能使用了。Starters包含了许多项目中需

要用到的依赖，它们能快速持续的运行，都是一系列得到支持的管理传递性依赖。

•SpringBoot自动配置原理是什么？

^@SpringBootApplication中有一个;主解@EnableAutoConfiguration,翻译成人话就是开启自

动配置而这个注解也是一个派生注解，其中的关键功能由@Import提供他有一个自动装配导入

转换器的类的一个selectlmports()方法通过FactoryNames()方法扫描所有具有META­

INF/spring.factories的jar包然后将所有自动配置类的值加载到Spring容器中。

•SpringBoot有哪几种读取配置的方式？

SpringBoot可以通过@PropertySource(加载制定文件)，@Value,@Environment,

@ConfigurationProperties来绑定变量,

•SpringBoot实现热部署有哪几种方式？

SpringLoadedSpring-boot-devtools

・你如彳可理解SpringBoot酉己置加载顺序?

1)properties文件；2)YAML文件；3)系统环境变量；4)命令行参数；

•SpringBoot装配Bean的原理

通过@EnableAutoConfiguration自动获取配置类信息，使用反射实例化为spring类，然后加载

到spring容器

•SpringBoot执行流程

使用SpringApplication.run（）启动,在方法所在类上添加@SpringBootApplication注解,这个

注解由@EnableAutoConfiguration和（康盘门特）@ComponentScan等注解组成,

@EnableAutoConfiguration自动加载SpringBoot配置和依赖包，默认使用

@ComponentScan扫描当前包及子包中的所有类，将有spring注解的类交给spring容器管理

•SpringCloud

•架构演变

•传统架构一分布式架构一SOA架构一微服务架构什么是分布式架构分布式架构就是将传

统结构按照模块进行拆分，不同的人负责不同的模块，不会产生代码冲突问题，方便开发。

・什么是SOA架构SOA架构就是将业务逻辑层提取出来，将相似的业务逻辑形成一个服务,提

供外部访问接口，服务之间访问通过RPC调用实现。

•什么是微服务架构微服务类似于SOA架构，但是比SOA架构粒度更细，更轻量。微服务架

构与SOA架构区别SOA是基于WebService和ESP实现，底层基于HTTP协议和使用XML

方式传输，XML在网络传输过程中会产生大量冗余。

・彳瓢员务由SOA架构演变而来，继承了SOA架构的优点，同时对SOA架构缺点进行改善，数

据传输采用JSON格式，相比于XML更轻量和快捷，粒度更细，更加便于敏捷开发。SOA数

据库会存在共享，微服务提倡每个服务连接独立的数据

・HTTP请求的执行漏呈

・用户在浏览器输入网址浏览器拿到网址后，通过DNS服务器查询网址的ip地址浏览器得到

ip地址后，和ip地址建立一条通道（TCP连接）三次握手

・浏览器向服务器发出一个请求，包括URL,协议版本号（http1.0等）,协议头（请求的方法get,客户

端cookie,agent信息等等），协议内容服务器拿到请求后，根据请求内容寻找相应的数据。

•如果找不到，返回错误码（例如404）如果能找到，返回内容（包括状态码,header头，例如是否

压缩，是否分段传输等等.返回实体内容）断开连接:T殳情况下，服务器关闭tcp连接,如果有

Connection:keep-alive,则不会关闭tcp,下次有请求的时候还是用同f连接浏览器拿到返回

数据后渲染页面

・TCPHTTP

•https:〃/s/jTDU-zxP1INTYLpGLypiXO

・TCP是什么

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。面向连接：一定是「一对一」

才能连接，不能像UDP协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做

到的；可靠的：无论的网络链路中出现了怎样的链路变化，TCP都可以保证一个报文一定能够

到达接收端；字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并

且消息是I■有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节已经收

至IJ,那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

・TCP三次握手过程

先是初始状态：客户端处于closed（关闭）状态，服务器处于listen（监听）状态。第一次握手：

建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT请求状态，等待服务

器确认；SYN:同步序列编号。第二次握手：服务器收到syn包，必须确认客户的SYN

（ack=j+l）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包，此时服务器进入

SYN_RECV接收状态；第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认

包ACK（ack=k+l）,此包发送完毕,客户端和服务器进入ESTABLISHED（已确认TCP连接

成功）状态，完成三次握手。

・如何在Linux系统中查看TCP状态？

TCP的连接状态查看，在Linux可以通过netstat-napt命令直看。

•为什么不是一次、二次握手？

防止了服务器端的一直等待而浪费资源。三次握手才可以同步双方的初始序列号三次握手才可

以阻止历史重复连接的初始化（主要原因）不使用「两次握手」和「四次握手」的原因：

「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序

列号；「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信

次数。

・TCP四次分手

•初始化状态：客户端和服务端都在连接状态，接下来开始进行四次分手断开连接操作。

•第一次分手：第一次分手无论是客户端还是服务端都可以发起这个请求

•第二次分手：服务端接收到客户端的释放请求连接之后，知道客户端没有数据要发给自己

了,然后服务端发送ACK=1告诉客户端收到你发给我的信息，此时服务端处于

CLOSE_WAIT等待关闭状态。

•第三次分手：此时服务端向客户端把所有的数据发送完了，然后发送一个FIN=1,用于告

诉客户端，服务端的所有数据发送完毕，客户端你也可以关闭接受数据连接了。此时服务

端状态处于LAT_ACK状态，来等待确认客户端是否收到了自己的请求。

•第四次分手：此时如果客户端收到了服务端发送完的信息之后，就发送ACK=1,告诉服

务端，客户端已经收到了你的信息，还会有一个2MSL的延迟等待，如果没问题就直接关

闭了

•为什么会有2MSL等待

因为要对应这样一种情况，最后客户端发送的ACK=1给服务端的过程中丢失了，服务端

没收到，服务端会认为我已经发送完数据了，怎么客户端为什么没回应我？是不是中途丢

失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL客户端给服务端发送

的ACK=1丢失，服务端等待1MSL没收到，然后重新发送消息需要1MSL。如果再次接

收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL,如果

没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方就都关闭

的连接,TCP四次分手就执行完毕了。

•为什么挥手需要四次？

关闭连接时，客户端向服务端发送FIN时，仅仅表示客户端不再发送数据了但是还能接收

数据。服务器收到客户端的FIN报文时，先回一个ACK应答报文，而服务端可能还有数

据需要处理和发送，等服务端不再发送数据时，才发送FIN报文给客户端来表示同意现在

关闭连接。从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端

的ACK和FIN一般都会分开发送，从而比三次握手导致多了一次。

・TCP与UDP区别

LTCP面向连接，UDP是无连接的2、TCP保证数据正确性，UDP可能丢包3、TCP保证

数据顺序，UDP不保证4、TCP面向字节流;UDP是面向报文的5、TCP要求系统资源较多，

UDP较少；

・网络七层模型

物理层：物理层负责最后将信息编码成电流脉冲或其它信号用于网上传输；数据链路层:数据

链路层通过物理网络链路供数据传输。不同的数据链路层定义了不同的网络和特征，其中包括物

理编址、网络结构、错误校验这些网络层网络层就是说负责在开始和终点之间建立连接;可以

理解为，要确定计算机的位置，怎么来确定？就可以用IPv4,IPv6!传输层就是说每一个应

用程序都会在网卡注册一个端口号，用来端口与端口的通信！常用的（TCP/IP）协议；会话

层会话层建立、管理和终止表示层与实体之间的通信会话；建立一个连接（自动的手机信息、

自动的网络寻址）；表示层：好像是可以解决不同系统之间的通信，eg:Linux下的QQ和

Windows下的QQ可以通信；应用层：

・UDP应用场景

网络数据大多为短消息对数据安全性无特殊要求网络负担非常重，但对响应速度要求高

•如果双方建立连接，一方出问题怎么办?

如果已经建立连接，但是服务端一直等待接收，发送端出现问题一直不能发送。所以可以设计

一个保活的计时器，如果一方出现问题，另一方过了这个计时器的时间，就发送试探报文，以

后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障,

接着就关闭连接。

•TCP字段意思

•TCP头部报文

一个是源端口号和目的端口号，源端口号就是指本地端口，目的端口就是远程端口。

•SequenceNumbe=序歹!I号

这个就是用于TCP通信过程中某T专输方向上一个字节流的每个字节的编号，就是为了确

保数据通信的有序性，避免网络中乱序的问题。接收端根据这个编号进行确认，保证分割

的数据段在原始数据包的位置。再通俗一点的讲，每个字段在传送中用序列号来标记自己

位置的，而这个字段就是用来完成双方传输中确保字段原始位置是按照传输顺序的。（发

送方是数据是怎样一个顺序，到了接受方也要确保是这个顺序）

・AcknowledgmentNumbe=确认序列号

确认序列号是用来接收，确认端就是说一个所期望收到的下一序列号。确认序号应该是是

上次已成功收到数据字节序号加1,只有当标志位中的ACK标志为1时该确认序列号的字

段才有效。主要用来解决不丢包的问题。

・TCPFlag

TCP首部中有6个标志比特，它们中的多个可同时被设置为1,主要是用于操控TCP的状

态机的，依次为URG,ACK,PSH,RST,SYN,FIN。

・ACK

这个标识可以理解为发送端发送数据到接收端，发送的时候ACK为0,标识接收端还未应

答，一旦接收端接收数据之后，就将ACK置为1,发送端接收到之后,就知道了接收端已

经接收了数据。

・SYN

就是用来建立TCP的连接，SYN标志位是和ACK标志位搭配使用，当连接请求的时候,

SYN=1,ACK=0连接被响应的时候，SYN=1,ACK=1;这个标志的数据包经常被用来进

行端口扫描。扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来，

就表明这台主机存在这个端口。

・FIN

表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发

送FIN标志位的TCP数据包后，连接就会被断开。这个很好理解，就是说,发送端只剩最

后的一段数据了，同时要告诉接收端后边没有数据可以接受了，所以用FIN标识一下，接

收端看到这个FIN之后，哦！这是接受的最后的数据，接受完就关闭了。

・Http协议的交互流程，和https的差异，ssl的交互流程

・Rest和Http什么关系？如彳于里解Rest风格

•TCP的滑动窗口

・HTTP常见的状态码，有哪些？

・204206200表示成功接收报文

•301302304重定向，资源位置发生变化，需要重新发送请求

•400403404客户端请求错误，请求报文有误，服务器无法处理

・500501502503服务器错误，处理请求发送错误

・说一下GET和POST的区别？

・Get方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频

等.

・比如，你打开我的文章，浏览器就会发送GET请求给服务器，服务器就会返回文章的所有

文字及资源。

•而POST方法则是相反操作，它向URI指定的资源提交数据，数据就放在报文的body里。

・比如，你在我文章底部，敲入了留言后点击「提交」（暗示你们留言），浏览器就会执行

一次POST请求，把你的留言文字放进了报文body里，然后拼接好POST请求头，通过

TCP协议发送给服务器。

•GET和POST方法都是安全和幕等的吗？

・在HTTP协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。

•所谓的「鬲等」，意思是多次执行相同的操作，结果都是「相同」的。

・那么很明显GET方法就是安全且幕等的，因为它是「只读」操作，无论操作多少次，服务

器上的数据都是安全的，且每次的结果都是相同的。

•POST因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多

次提交数据就会创建多个资源，所以不是鬲等的。

・你知道的HTTP（1.1）的优点有哪些，怎么体现的？

•HTTP最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

・1.简单

・HTTP基本的报文格式就是header+body,头部信息也是key-value简单文本的形式，

易于理解，降低了学习和使用的门槛。

・2.灵活和易于扩展

・HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,

都允许开发人员自定义和扩充。

・同时HTTP由于是工作在应用层（OSI第七层），则它下层可以随意变化。

・HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层,HTTP/3甚至把

TCPP层换成了基于UDP的QUIC.

・3.应用广泛和跨平台

・互联网发展至今，HTTP的应用范围非常的广泛，从台式机的浏览器到手机上的各种APP,

从看新闻、刷贴吧到购物、理财、吃鸡，HTTP的应用片地开花，同时天然具有跨平台的优

越性。

•那它的缺点呢？

・1无状态双刃剑

HTTP协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点

「不安全」。1.无状态双刃剑无状态的好处，因为服务器不会去记忆HTTP的状态，所以

不需要额外的资源来记录状态信息，这能减轻^务器的负担，能够把更多的CPU和内存用

来对外提供服务。无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时

会非常麻烦。例如登录-＞添加购物车-＞下单-＞结算-＞支付，这系列操作都要知道用户的

身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。这样每操作

一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是酸爽！对于无状态的问

题，解法方案有很多种，其中比较简单的方式用Cookie技术。Cookie通过在请求和响应

报文中写入Cookie信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器

会下发一个装有客户信息的「小贴纸」,后续客户端请求服务器的时候，带上「小贴纸」,

服务器就能认得了了，

・2明文传输双刃剑

明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的F12控制台或

Wireshark抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。但是这正是这

样，HTTP的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，

信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号

没了。

•3不安全

HTTP比较严重的缺点就是不安全：通信使用明文（不加密），内容可能会被窃听。比如，

账号信息容易泄漏，那你号没了。不验证通信方的身份，因此有可能遭遇伪装。比如，访

问假的淘宝、拼多多，那你钱没了。无法证明报文的完整性，所以有可能已遭篡改。比如，

网页上植入垃圾广告，视觉污染，眼没了。HTTP的安全问题，可以用HTTPS的方式解决，

也就是通过引入SSL/TLS层，使得在安全上达到了极致。

・HTTP与HTTPS有哪些区别？

HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安

全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。

HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP

三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输。HTTP的端口号是

80,HTTPS的端口号是443。HTTPS协议需要向CA（证书权威机构）申请数字证书，来保

证^务器的身份是可信的。

•HTTPS解决了HTTP的哪些问题？

HTTP由于是明文传输，所以安全上存在以下三个风险：窃听风险，比如通信链路上可以获取

通信内容，用户号容易没。篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎。冒充

风险，比如冒充淘宝网站，用户钱容易没。HTTPS在HTTP与TCP层之间加入了SSL/TLS协

议。可以很好的解决了上述的风险：信息加密：交互信息无法被窃取，但你的号会因为「自

身忘记」账号而没。校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度I■竞价排

名」依然可以搜索垃圾广告。身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为I■剁手」

而没。可见，只要自身不做「恶」，SSL/TLS协议是能保证通信是安全的。

・HTTP协议有哪些方法

・一次HTTP请求的全过程，包括域名解析、定位主机等

・微服务遇见的坑

•SpringCloud有什么优势

・为什么需要学习SpringCloud

・不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。

・但是，随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。

・这就会给应用带来很多问题：代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。

同时，这也会给业务的快速迭代带来巨大挑战；开发效率变低：开发人员同时开发一套代码，

很难避免代码冲突。

・开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；排查解决问题成本高：

线上业务发现bug，修复bug的过程可能很简单。

•什么是SpringCloud

・SpringCloud是很多框架的一个集合。

・它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、

配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的

开发风格做到一键启动和部署。

・SpringCloud并没有重复制造轮子，它只是将很多家公司开发的比较成熟、经得起实际考验的

服务框架组合起来,通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终

给开发者留出了一套比较简单易懂、容易易部署和维护的分布式系统的一个开发工具包。

・SpringCloud优缺点

优点：出生Spring大家族，可以保证后续的更新、完善。组件和功能很丰富也很齐全，例如、配

置管理、服务发现、断路器、微服务网关等；SpringCloud社区活跃度很高，教程也很丰富，遇

到问题很容易找到解决方案；服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于

提高开发效率可以更精准的制定优化服务方案，提高系统的可维护性也减轻团队的成本，可以并

行开发，不用关注其他人怎么开发，专业的人做专业的事嘛先他适于互联网时代，产品迭代周期也

比较短缺点：微服务过多，治理成本高，不利于维护系统分布式系统开发的成本高有（容错，分

布式事务等问题）

・SpringCloud组件

SpringCloudNetflix:NetflixOSS开源组件集成,包括Eureka、Hystrix,Ribbon,Feign、

Zuul等核心组件。Eureka:服务治理组件，包括服务端的注册中心和客户端的服务发现机制；

Ribbon:负载均衡的服务调用组件，具有多种负载均衡调用策略；Hystrix:服务容错组件，实现

了断路器模式，为依赖服务的出错和延迟提供了容错能力；Feign:基于Ribbon和Hystrix的声

明式服务调用组件；Zuul:API网关组件，对请求提供路由及过滤功能。SpringCloudBus:用

于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷

新集群中的服务配置。SpringCloudSecurity（思ki味儿提）他是安全工具包，有一个

OAuth2客户端及登录认证进行支持。SpringCloudSleuth（苏斯）SpringCloud应用程序的分

布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。SpringCloud

GatewayAPI网关组件，对请求提供路由及过滤功能。SpringCloudOpenFeign基于Ribbon

和Hystrix的声明式服务调用组件，可以动态创建基于SpringMVC注解的接口实现用于服务调用，

在SpringCloud2.0中已经取代Feign.

•SpringBoot和SpringCloud的区别?

SpringBoot专注于快速方便的开发单个个体微服务。SpringCloud是关注全局的微服务的协调整

理和治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，还为各个微服务之间

提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话

等等集成服务SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开

SpringBoot,属于依赖的关系SpringBoot专注于快速、方便的开发单个微服务个体，

SpringCloud关注全局的服务治理框架。

・SpringBoot开发分布式微服务时，我们面I缶的问题

(1)与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。(2)

服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈.它涉及一个服务目录，在

该目录中注册服务，然后能够查找并连接到该目录中的服务。(3)冗余-分布式系统中的冗余问题。

(4)负载平衡--负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路,

中央处理单元，或磁盘驱动器的分布。(5)性能-问题由于各种运营开销导致的性能问题。(6)

部署复杂性-Devops技能的要求。

•服务注册和发现是什么意思?SpringCloud如何实现？

就是说当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发

和部署，添加和修改这些属性变得更加复杂。有些服务性能可能会下降，而某些位置可能会发生变

化.手动更改属性可能会产生问题。Eureka服务注册和发现可以解决这个问题将所有服务都在

Eureka服务器上注册并通过调用Eureka服务器完成查找，就可以解决服务任何更改和处理了。

•SpringCloud和dubbo区别？

dubbo由于是二进制的传输，占用带宽会更少SpringCloud是http协议传输，带宽会比较多，同

时使用http协议一般会使用JSON报文，消耗会更大dubbo的开发难度较大，好像是是dubbo

有jar包依赖问题，不知道现在解决没有dubbo的注册中心可以选择zk,redis等多种，

springcloud的注册中心只能用eureka或者自研dubbo服务网关，分布式配置服务追踪什么的好

像都不是很完善，cloud的话则提供的还可以

・Eureka和Zookeeper区另！|

•1.Eureka取CAP的AP,注重可用性，Zookeeper取CAP的CP注重一致性。2.Zookeeper

在选举期间注册服务会瘫痪，虽然服务最终会恢复，但选举期间不可用。

•3.eureka的自我保护机制，他不会再从注册列表去移除因长时间没收到心跳而过期的服务。依

然能接受新服务的注册和查询请求，但不会被同步到其他节点。不会服务瘫痪。

•4.Zookeeper有Leader和Follower角色,Eureka各个节点平等。

・5.Zookeeper采用过半数存活原则，Eureka采用自我保护机制解决分区问题。

•6.eureka本质是一个工程，Zookeeper只是一个进程。

・eureka自我保护机制是什么?

当EurekaServer节点在短时间内丢失了过多实例的连接时（比如网络故障或频繁启动关闭客户端）

节点会进入自我保护模式，保护注册信息，不再删除注册数据，故障恢复时，就会自动退出自我保

护模式。

•Nginx与Ribbon的区另［|

Nginx是反向代理，同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡策略根据

upstream配置进行转发，相当于请求通过nginx服务器进行转发。Ribbon是客户端负载均衡，

从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。

•Ribbon底层实现原理

Ribbon使用（迪斯卡娃儿瑞可蓝的）discoveryclient从注册中心读取目标服务信息，对同一接

口请求进行计数，使用％取余算法获取目标服务集群索引，返回获取到的目标服务信息。

・常见的限流手段

计数器、滑动窗口、漏桶、令牌。

・计数器

"计数器是一种比较简单的限流算法，用途比较广泛，在接口层面，很多地方使用这种方式限

流。在一段时间内,进行计数，与阀值进行比较，到了时间临界点，将计数器清0。

•java

•Hashmap

•如何解决hash冲突问题？

使用链表存放hash值，相等且内容不等,存放在同一个链表里面

•HashmapPUT方法底层实现

L判断table是否为空，是空的就执行resize扩容2.如果不为空就根据key计算hash值得到

数组索引，如果table为空直接，新建节点添加，如果不为空就判断table的首个元素是否和

key一样，如果相同就直接覆盖3.还会判断table是否是红黑树，如果是就在红黑树里面插入

键值对4.如果不是则会遍历table,判断链表长度是否大于8,大于8就把链表转换为红黑树，

否则进行链表的插入操作，如果key已经存在，直接覆盖value即可5.插入成功以后判断实际

存在的键值对是否超出了最大容量，如果超出就扩容默认初始容量为16.加载因子大小是

16*0.75=12，大于12,每次扩容是*2GET实现：获取首节点,hash碰撞概率小,通常链表

第一个节点就是值，没必要去循环如果不止一个节点，就需要循环遍历,存在多个hash碰撞

判断是否是红黑树，如果是则调用树的查找

•Hashmap加载因子为什么是0.75?

•折中方案，空间利用率高，冲突少0.75最合适

•Hashmapl.7数组扩容死循环问题

因为map数组扩容的链表采用头插入法头插入法相当于让最新的冲突节点存放到最前，在多

线程的情况下操作map,导致死循环问题尾插入相反

•hashmap底层

・hash方法：让key的hash值的高十六位也参与运算，key如果等于null,hash就是0,

存放在数组0的位置

・Hap根据key查询时间复杂度是多少

Map根据key直接计算index值，直接从数组中查询数据如何indxe没冲突直接获取复杂度

为01如果冲突，遍历链表就是on

・1.8改进了哪些地方

1.1.8map采用尾部插入法2.解决了map死循环的问题3.链表长度大于8转成红黑树小于

6转换成链表

・为什么要引入红黑树

•红黑树，为什么允许局部不平衡

・因为index冲突过多，导致链表过长，为了解决链表直询效率慢，这时候大于8数组容量

大于64就转换成了红黑树存放，时间复杂度从On变为O(logn)

・Map不安全有安全的替代方案嘛

・ConcurrentHashm叩采用分段锁16段，1.8引入了CAS无锁机制

・ConcurrentHashMap

ConcurrentHashM叩线程安全的Map,hashtable类基本上所有的方法都是采用

synchronized进行线程安全控制高并发情况下效率就降低ConcurrentHashMap是采用了

分段锁的思想提高性能，锁粒度更细化

・jdkl.7和jdkl.8里面ConcurrentHashMap实现的区别有没了解

JDK8之前，ConcurrentHashMap使用锁分段技术，将数据分成一段段存储，每个数据段配

置一把锁，即segment类，这个类继承ReentrantLock来保证线程安全技术点：

Segment+HashEntryJKD8的版本取消Segment这个分段锁数据结构，底层也是使用Node

数组+链表+红黑树，从而实现对每一段数据就行加锁，也减少了并发冲突的概率，

CAS(读)+Synchronized(写)技术点：Node+Cas+Synchronized

・ConcurrentHashMapPUT的核心逻辑(1.8)

put的核心流程1、key进行重哈希spread(key.hashCode())2、对当前table进行无条件循

环3、如果没有初始化table,则用initTable进行初始化4、如果没有hash冲突，则直接用

cas插入新节点，成功后则直接判断是否需要扩容，然后结束5、(fh=f.hash)==MOVED如

果是这个状态则是扩容操作,先进行扩容6、存在hash冲突，利用synchronized(f)加锁保证

线程安全7、如果是链表，则直接遍历插入，如果数量大于8,则需要转换成红黑树8、如果是

红黑树则按照红黑树规则插入9、最后是检查是否需要扩容addCount()

•Hashmap工作原理

我们通过put()和get()方法储存和获取对象。当我们将键值对传递给put()方法时，它调用健对

象的hashCodeO方法来计算hashcode,让后找到bucket位置来储存值对象。当获取对象时,

通过键对象的equals。方法找到正确的键值对，然后返回值对象。HashMap使用链表来解决

碰撞问题，当发生碰撞了，对象将会储存在链表的下一个节点中.HashMap在每个链表节点

中储存键值对对象。

・当两个不同的健对象的hashcode相同时会发生什么？

它们会储存在同一个bucket位置的链表中。键对象的equals。方法用来找到键值对。

•为什么重写了equals方法要重写hashcode

・重写equals。方法同时重写hashcode()方法，就是为了保证当两个对象通过equals。方法

比较相等时，那么他们的hashCode值也一定要保证相等，如果不这样的话，只重写

equals,判断值相等，但是无法判断同一个对象是否相等，不重写用的就是。bject里面的

hashcode方法

•两个对象相等，hashcode一定相等

•两个对象不等，hashcode不一定不等

•hashcode相等，两个对象不一定相等

•hashcode不等，两个对象一定不等

・hashmap容量为什么是2的幕次

・hash算法考虑的点有哪些

•什么是hash

•hash也称散列，哈希，原理就是把任何长度的输入，通过hash算法变成固定的长度的输

出

•hash特点：从hash值不可以反向推导出原始数据

•输入的数据微小变化，会得到不同的hash值，相同的数据会得到相同的值

•hash算法执行效率要高，长文本也要快速算出哈希值

・hash算法冲突概率要小

•hashmap结构

・Node

・Node实现了Map.Entry里面有四个属性

・hash

•key

・value

•next

・你知道hash的实现吗？为什么要这样实现？

JDK1.8中,是通过hashCodeO的高16位异或低16位实现的:(h=k.hashCodeO)A

(h>>>16),主要是从速度，功效和质量来考虑的，减少系统的开销，也不会造成因为高位没

有参与下标的计算，从而引起的碰撞。

•为什么要用异或运算符？

保证了对象的hashCode的32位值只要有一位发生改变，整个hash()返回值就会改变。尽可

能的减少碰撞。

•HashMap的table的容量如何确定？loadFactor是什么？该容量如何变化?这种变化会带来

什么问题？

•①、table数组大小是由opacity这个参数确定的，默认是16,也可以构造时传入，最大

限制是1<<30;

・②、loadFactor是装载因子，主要目的是用来确认table数组是否需要动态扩展，默认值

是0.75，比如table数组大小为16,装载因子为0.75时,threshold就是12,当table

的实际大小超过12时，table就需要动态扩容；

•③、扩容时，调用resizeO方法，将table长度变为原来的两倍(注意是table长度，而

不是threshold)

•④、如果数据很大的情况下，扩展时将会带来性能的损失，在性能要求很高的地方，这种

损失很可能很致命。

•HashMap中put方法的过程？

・调用哈希函数获取Key对应的hash值，再计算其数组下标；

・如果没有出现哈希冲突，则直接放入数组；如果出现哈希冲突，则以链表的方式放在链表

后面；

・如果链表长度超过阀值(TREEIFYTHRESHOLD==8),就把链表转成红黑树，链表长度低

于6,就把红黑树转回链表；

・如果结点的key已经存在，则替换其value即可；

•如果集合中的键值对大于12,调用resize方法进行数组扩容。"

•数组扩容的过程?

・创建一个新的数组，其容量为旧数组的两倍，并重新计算旧数组中结点的存储位置。结点

在新数组中的位置只有两种,原下标位置或原下标+旧数组的大小。

・拉链法导致的链表过深问题为什么不用二叉查找树代替，而选择红黑树？为什么不一直使用红

黑树？

・所以选择红黑树是为了解决二叉查找树的缺陷，二叉查找树在特殊情况下会变成一条线性

结构(这就跟原来使用链表结构一样了，造成很深的问题)，遍历查找会非常慢。

•而红黑树在插入新数据后可能需要通过左旋，右旋、变色这些操作来保持平衡，引入红黑

树就是为了查找数据快，解决链表查询深度的问题，我们知道红黑树属于平衡二叉树，但

是为了保持"平衡”是需要付出代价的，但是该代价所损耗的资源要比遍历线性链表要少,

所以当长度大于8的时候，会使用红黑树，如果链表长度很短的话，根本不需要引入红黑

树，引入反而会慢。

•说说你对红黑树的见解？

・L每个节点非红即黑

・2、根节点总是黑色的

•3、如果节点是红色的，则它的子节点必须是黑色的（反之不一定）

・4、每个叶子节点都是黑色的空节点（NIL节点）

•5、从根节点到叶节点或空子节点的每条路径，必须包含相同数目的黑色节点（即相同的黑

色高度）

•jdk8中对HashMap做了哪些改变？

・在java1.8中，如果链表的长度超过了8,那么链表将转换为红黑树。（桶的数量必须大

于64，小于64的时候只会扩容）

•发生hash碰撞时，java1.7会在链表的头部插入，而java1.8会在链表的尾部插入

•在java1.8中，Entry被Node替代（换了一个马甲）。

•JDK7存在死循环和数据丢失问题

・数据丢失

・并发赋值被覆盖：在createEntry方法中，新添加的元素直接放在头部，使元素之后

可以被更快访问，但如果两个线程同时执行到此处，会导致其中一个线程的赋值被覆盖。

•已遍历区间新增元素丢失：当某个线程在transfer方法迁移时，其他线程新增的元素

可能落在已遍历过的哈希槽上。遍历完成后，table数组引用指向了newTable,新增

元素丢失。

・新表被覆盖：如果resize完成，执行了table=newTable,则后续元素就可以在新

表上进行插入。但如果多线程同时resize,每个线程都会new一个数组，这是线程内

的局部对象，线程之间不可见。迁移完成后resize的线程会赋值给table线程共享变

量，可能会覆盖其他线程的操作，在新表中插入的对象都会被丢弃。

•死循环

•扩容时resize调用transfer使用头插法迁移元素，虽然newTable是局部变量，但原

先table中的Entry链表是共享的，问题根源是Entry的next指针并发修改，某线程

还没有将table设为newTable时用完了CPU时间片，导致数据丢失或死循环。

・JDK8在resize方法中完曲广容，并改用尾插法，不会产生死循环，但并发下仍可能丢

失数据。可用ConcurrentHashMap或Collections.synchronizedMap包装成同步集

合。

•HashMap,LinkedHashMap,TreeMap有什么区另！J?

•HashMap参考其他问题；

•LinkedHashMap保存了记录的插入顺序，在用Iterator遍历时，先取到的记录肯定是先

插入的；遍历比HashMap慢；

•TreeMap实现SortMap接口，能够把它保存的记录根据键排序（默认按键值升序排序，

也可以指定排序的比较器）

•HashMap&TreeMap&LinkedHashMap使用场景？

・一般情况下，使用最多的是HashMap。

・HashMap:在Map中插入、删除和定位元素时；

・TreeMap:在需要按自然顺序或自定义顺序遍历键的情况下；

•LinkedHashM叩：在需要输出的顺序和输入的顺序相同的情况下。

•HashMap和HashTable有什么区别？

・①、HashM叩是线程不安全的，HashTable是线程安全的；

•②、由于线程安全，所以HashTable的效率比不上HashMap;

・③、HashMap最多只允许一条记录的key为null,存放在第0个位置，允许多条记录的

值为null,而HashTable不允许；

•④、HashMap默认初始化数组的大小为16,HashTable为11,前者扩容时，扩大两倍，

后者扩大两倍+1；

•⑤、HashMap需要重新计算hash值，而HashTable直接使用对象的hashCode

・HashMap&ConcurrentHashMap的区另!l?

•除了加锁，原理上无太大区别。另外，HashMap的键值对允许有null,但是

ConCurrentHashMap都不允许。

•为什么ConcurrentHashMap比HashTable效率要高?

•HashTable使用一把锁（锁住整个链表结构）处理并发问题，多个线程竞争一把锁，容易

阻塞；

・ConcurrentHashMap

・JDK1.7中使用分段锁（ReentrantLock+Segment+HashEntry）,相当于把一个

HashMap分成多个段，每段分配一把锁，这样支持多线程访问。锁粒度：基于Segment,

包含多个HashEntry.

•JDK1.8中使用CAS+synchronized+Node+红黑树。锁粒度：Node（首结点）（实

现M叩.Entry<K,V>）。锁粒度降低了。

・针对ConcurrentHashMap锁机制具体分析（JDK1.7VSJDK1.8）?

・JDK1.7中，采用分段锁的机制，实现并发的更新操作，底层采用数组+链表的存储结构，

包括两个核心静态内部类Segment和HashEntry。

•①、Segment继承ReentrantLock（重入锁）用来充当锁的角色，每个Segment对象

守护每个散列映射表的若干个桶；

.②、HashEntry用来封装映射表的键-值对；

・③、每个桶是由若干个HashEntry对象链接起来的链表

•JDK1.8中,采用Node+CAS+Synchronized来保证并发安全。取消类Segment,直

接用table数组存储键值对；

•当HashEntry对象组成的链表长度超过TREEIFY_THRESHOLD时，链表转换为红黑树，

提升性能。底层变更为数组+链表+红黑树。

•ConcurrentHashMap在JDK1.8中，为什么要使用内置锁synchronized来代替重入锁

ReentrantLock?

・①、粒度降低了；

・②、JVM开发团队没有放弃synchronized,而且基于JVM的synchronized优化空间更

大，更加自然。

•③、在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更

多的内存。

•为什么ConcurrentHashMap的读操作不需要加锁？

•jdkl.7中是采用Segment+HashEntry+ReentrantLock的方式进行实现的，而1.8中

放弃了Segment臃肿的设计,取而代之的是采用Node+