博客记录-day112-Java基础面试题+计网网络模型、应用层面试题

104 阅读23分钟

一、语雀-Java基础面试题

1、Java序列化的原理是啥

✅Java序列化的原理是啥

image.png

image.png

2、serialVersionUID 有何用途? 如果没定义会有什么问题

✅serialVersionUID 有何用途? 如果没定义会有什么问题?

image.png

3、Java中异常分哪两类,有什么区别?

✅Java中异常分哪两类,有什么区别?

image.png

以下是各个异常的详细解释及处理方法:

1. BufferOverflowException

原因:向缓冲区写入数据时超出其容量限制。 • 示例:使用 ByteBufferput() 方法时,缓冲区已满仍继续写入。 • 处理: ◦ 检查缓冲区容量,使用 hasRemaining() 判断是否有空间。 ◦ 调用 clear() 重置缓冲区,或 flip() 切换到读模式后重新分配。

2. BufferUnderflowException

原因:从缓冲区读取数据时,未提供足够的数据。 • 示例:未调用 flip() 就直接读取 ByteBuffer。 • 处理: ◦ 确保读取前调用 flip() 标记数据起始位置。 ◦ 使用 remaining() 检查剩余数据量,避免超额读取。

3. CannotRedoException & CannotUndoException

原因: ◦ CannotUndoException:撤销操作时无历史记录。 ◦ CannotRedoException:重做操作时无后续步骤。 • 示例:用户连续撤销多次后尝试再次撤销。 • 处理: ◦ 在执行撤销/重做前,检查历史记录是否为空(如 UndoManagercanUndo()/canRedo())。 ◦ 提供用户反馈(如“无更多撤销操作”)。

4. ClassCastException

原因:强制转换对象到不兼容的类型。 • 示例Object obj = new Integer(5); String str = (String) obj;处理: ◦ 转换前使用 instanceof 验证类型:if (obj instanceof String)。 ◦ 避免不必要的强制转换,合理设计代码结构。

6. ConcurrentModificationException

原因:迭代集合时,另一线程修改了集合结构。 • 示例:用 Iterator 遍历 ArrayList 时,其他线程调用 remove()。 • 处理: ◦ 使用线程安全集合:CopyOnWriteArrayListConcurrentHashMap。 ◦ 同步迭代和修改操作(如 synchronized 块)。

7.总结表

异常名称原因解决方案
BufferOverflowException写入超出缓冲区容量检查缓冲区状态,重置或扩展容量
BufferUnderflowException读取时缓冲区数据不足确保读取前数据已正确填充
CannotRedoException无重做历史记录检查历史记录,禁止无效操作
CannotUndoException无撤销历史记录同上
ClassCastException类型转换不兼容使用 instanceof 验证类型
ConcurrentModificationException集合并发修改使用线程安全集合或同步控制

8.说一说个Java异常处理相关的几个关键字,以及简单用法。

  • throws、throw、try、catch、finally
  • try用来指定一块预防所有异常的程序;
  • catch子句紧跟在try块后面,用来指定你想要捕获的异常的类型;
  • finally为确保一段代码不管发生什么异常状况都要被执行;
  • throw语句用来明确地抛出一个异常;
  • throws用来声明一个方法可能抛出的各种异常;

4、Java是值传递还是引用传递?

✅Java是值传递还是引用传递?

image.png

image.png

5、SimpleDateFormat是线程安全的吗?使用时应该注意什么?

✅SimpleDateFormat是线程安全的吗?使用时应该注意什么?

image.png

6、JDK新版本中都有哪些新特性?

✅JDK新版本中都有哪些新特性? image.png

7、为什么JDK 9中把String的char[]改成了byte[]?

✅为什么JDK 9中把String的char[]改成了byte[]?

image.png

8、字符串常量是什么时候进入到字符串常量池的?

✅字符串常量是什么时候进入到字符串常量池的?

image.png

image.png

9、有了equals为啥需要hashCode方法?

✅有了equals为啥需要hashCode方法?

image.png

image.png

10、怎么修改一个类中的private修饰的String参数的值

✅怎么修改一个类中的private修饰的String参数的值

image.png

image.png

image.png

11、反射与封装是否矛盾?如何解决反射破坏封装不安全的问题?

✅反射与封装是否矛盾?如何解决反射破坏封装不安全的问题?

image.png

image.png

二、小林-计网网络模型面试题

1、网络OSI模型和TCP/IP模型分别介绍一下

OSI七层模型

为了使得多种设备能通过网络相互通信,和为了解决各种不同设备在网络互联中的兼容性问题,国际标准化组织制定了开放式系统互联通信参考模型(Open System Interconnection Reference Model),也就是 OSI 网络模型,该模型主要有 7 层,分别是应用层、表示层、会话层、传输层、网络层、数据链路层以及物理层。

img

每一层负责的职能都不同,如下:

  • 应用层,负责给应用程序提供统一的接口;
  • 表示层,负责把数据转换成兼容另一个系统能识别的格式;
  • 会话层,负责建立、管理和终止表示层实体之间的通信会话;
  • 传输层,负责端到端的数据传输;
  • 网络层,负责数据的路由、转发、分片;
  • 数据链路层,负责数据的封帧和差错检测,以及 MAC 寻址;
  • 物理层,负责在物理网络中传输数据帧;

由于 OSI 模型实在太复杂,提出的也只是概念理论上的分层,并没有提供具体的实现方案。

事实上,我们比较常见,也比较实用的是四层模型,即 TCP/IP 网络模型,Linux 系统正是按照这套网络模型来实现网络协议栈的。

TCP/IP模型

TCP/IP协议被组织成四个概念层,其中有三层对应于ISO参考模型中的相应层。ICP/IP协议族并不包含物理层和数据链路层,因此它不能独立完成整个计算机网络系统的功能,必须与许多其他的协议协同工作。TCP/IP 网络通常是由上到下分成 4 层,分别是应用层,传输层,网络层和网络接口层

img

  • 应用层 支持 HTTP、SMTP 等最终用户进程
  • 传输层 处理主机到主机的通信(TCP、UDP)
  • 网络层 寻址和路由数据包(IP 协议)
  • 链路层 通过网络的物理电线、电缆或无线信道移动比特

三、小林-计网应用层面试题

1、应用层有哪些协议?

HTTP、HTTPS、CDN、DNS、FTP 都是应用层协议

2、HTTP报文有哪些部分?

img

分请求报文和响应报文来说明。

请求报文:

  • 请求行:包含请求方法、请求目标(URL或URI)和HTTP协议版本。
  • 请求头部:包含关于请求的附加信息,如Host、User-Agent、Content-Type等。
  • 空行:请求头部和请求体之间用空行分隔。
  • 请求体:可选,包含请求的数据,通常用于POST请求等需要传输数据的情况。

响应报文:

  • 状态行:包含HTTP协议版本、状态码和状态信息。
  • 响应头部:包含关于响应的附加信息,如Content-Type、Content-Length等。
  • 空行:响应头部和响应体之间用空行分隔。
  • 响应体:包含响应的数据,通常是服务器返回的HTML、JSON等内容。

3、HTTP常用的状态码?

img

HTTP 状态码分为 5 大类

  • 1xx 类状态码属于提示信息,是协议处理中的一种中间状态,实际用到的比较少。
  • 2xx 类状态码表示服务器成功处理了客户端的请求,也是我们最愿意看到的状态。
  • 3xx 类状态码表示客户端请求的资源发生了变动,需要客户端用新的 URL 重新发送请求获取资源,也就是重定向
  • 4xx 类状态码表示客户端发送的报文有误,服务器无法处理,也就是错误码的含义。
  • 5xx 类状态码表示客户端请求报文正确,但是服务器处理时内部发生了错误,属于服务器端的错误码。

其中常见的具体状态码有:

  • 200:请求成功;
  • 301:永久重定向;302:临时重定向;
  • 404:无法找到此页面;405:请求的方法类型不支持;
  • 500:服务器内部出错。

4、HTTP返回状态301 302分别是什么?

3xx 类状态码表示客户端请求的资源发生了变动,需要客户端用新的 URL 重新发送请求获取资源,也就是重定向

  • 301 Moved Permanently」表示永久重定向,说明请求的资源已经不存在了,需改用新的 URL 再次访问。
  • 302 Found」表示临时重定向,说明请求的资源还在,但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location,指明后续要跳转的 URL,浏览器会自动重定向新的 URL。

5、http 502和 504 的区别?

  • 502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
  • 504 Gateway Time-out:作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器收到响应。

举一个例子,假设 nginx 是代理服务器,收到客户端的请求后,将请求转发到后端服务器(tomcat 等)。

  • 当nginx收到了无效的响应时,就返回502。
  • 当nginx超过自己配置的超时时间,还没有收到请求时,就返回504错误。

6、HTTP层请求的类型有哪些?

  • GET:用于请求获取指定资源,通常用于获取数据。
  • POST:用于向服务器提交数据,通常用于提交表单数据或进行资源的创建。
  • PUT:用于向服务器更新指定资源,通常用于更新已存在的资源。
  • DELETE:用于请求服务器删除指定资源。
  • HEAD:类似于GET请求,但只返回资源的头部信息,用于获取资源的元数据而不获取实际内容。

7、GET和POST的使用场景,有哪些区别?

根据 RFC 规范,GET 的语义是从服务器获取指定的资源,这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中,URL 规定只能支持 ASCII,所以 GET 请求的参数只允许 ASCII 字符 ,而且浏览器会对 URL 的长度有限制(HTTP协议本身对 URL长度并没有做任何规定)。

比如,你打开我的文章,浏览器就会发送 GET 请求给服务器,服务器就会返回文章的所有文字及资源。

image-20240725231737529

根据 RFC 规范,POST 的语义是根据请求负荷(报文body)对指定的资源做出处理,具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中,body 中的数据可以是任意格式的数据,只要客户端与服务端协商好即可,而且浏览器不会对 body 大小做限制。

比如,你在我文章底部,敲入了留言后点击「提交」,浏览器就会执行一次 POST 请求,把你的留言文字放进了报文 body 里,然后拼接好 POST 请求头,通过 TCP 协议发送给服务器。

image-20240725231722256

如果从 RFC 规范定义的语义来看:

  • GET 方法就是安全且幂等的,因为它是「只读」操作,无论操作多少次,服务器上的数据都是安全的,且每次的结果都是相同的。所以,可以对 GET 请求的数据做缓存,这个缓存可以做到浏览器本身上(彻底避免浏览器发请求),也可以做到代理上(如nginx),而且在浏览器中 GET 请求可以保存为书签
  • POST 因为是「新增或提交数据」的操作,会修改服务器上的资源,所以是不安全的,且多次提交数据就会创建多个资源,所以不是幂等的。所以,浏览器一般不会缓存 POST 请求,也不能把 POST 请求保存为书签

但是实际过程中,开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如:

  • 可以用 GET 方法实现新增或删除数据的请求,这样实现的 GET 方法自然就不是安全和幂等。
  • 可以用 POST 方法实现查询数据的请求,这样实现的 POST 方法自然就是安全和幂等。

8、HTTP默认的端口是什么?

http 是 80,https 默认是 443。

9、HTTP1.1怎么对请求做拆包,具体来说怎么拆的?

在HTTP/1.1中,请求的拆包是通过"Content-Length"头字段来进行的。该字段指示了请求正文的长度,服务器可以根据该长度来正确接收和解析请求。

image-20240725231532943

具体来说,当客户端发送一个HTTP请求时,会在请求头中添加"Content-Length"字段,该字段的值表示请求正文的字节数。

服务器在接收到请求后,会根据"Content-Length"字段的值来确定请求的长度,并从请求中读取相应数量的字节,直到读取完整个请求内容。

这种基于"Content-Length"字段的拆包机制可以确保服务器正确接收到完整的请求,避免了请求的丢失或截断问题。

10、HTTP为什么不安全?

HTTP 由于是明文传输,所以安全上存在以下三个风险:

  • 窃听风险,比如通信链路上可以获取通信内容,用户号容易没。
  • 篡改风险,比如强制植入垃圾广告,视觉污染,用户眼容易瞎。
  • 冒充风险,比如冒充淘宝网站,用户钱容易没。

img

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议,可以很好的解决了上述的风险:

  • 信息加密:交互信息无法被窃取,但你的号会因为「自身忘记」账号而没。
  • 校验机制:无法篡改通信内容,篡改了就不能正常显示,但百度「竞价排名」依然可以搜索垃圾广告。
  • 身份证书:证明淘宝是真的淘宝网,但你的钱还是会因为「剁手」而没。

11、HTTP和HTTPS 的区别?

区别主要有以下四点:

  • HTTP 是超文本传输协议,信息是明文传输,存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输。
  • HTTP 连接建立相对简单, TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后,还需进行 SSL/TLS 的握手过程,才可进入加密报文传输。
  • 两者的默认端口不一样,HTTP 默认端口号是 80,HTTPS 默认端口号是 443。
  • HTTPS 协议需要向 CA(证书权威机构)申请数字证书,来保证服务器的身份是可信的。

12、HTTPS是如何防范中间人的攻击?

主要通过加密和身份校验机制来防范中间人攻击的:

  • 加密:https 握手期间会通过非对称加密的方式来协商出对称加密密钥。
  • 身份校验:服务器会向证书颁发机构申请数字证书,证书中包含了服务器的公钥和其他相关信息。当客户端与服务器建立连接时,服务器会将证书发送给客户端。客户端会验证证书的合法性,包括检查证书的有效期、颁发机构的信任等。如果验证通过,客户端会使用证书中的公钥来加密通信数据,并将加密后的数据发送给服务器,然后由服务端用私钥解密。

中间人攻击的关键在于攻击者冒充服务器与客户端建立连接,并同时与服务器建立连接。

但由于攻击者无法获得服务器的私钥,因此无法正确解密客户端发送的加密数据。同时,客户端会在建立连接时验证服务器的证书,如果证书验证失败或存在问题,客户端会发出警告或中止连接。

13、Http1.1和2.0的区别是什么?

HTTP/2 相比 HTTP/1.1 性能上的改进:

  • 头部压缩:HTTP/2 会压缩头(Header)如果你同时发出多个请求,他们的头是一样的或是相似的,那么,协议会帮你消除重复的部分。这就是所谓的 HPACK 算法:在客户端和服务器同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
  • 二进制格式:HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文,而是全面采用了二进制格式,头信息和数据体都是二进制,并且统称为帧(frame):头信息帧(Headers Frame)和数据帧(Data Frame) 。这样虽然对人不友好,但是对计算机非常友好,因为计算机只懂二进制,那么收到报文后,无需再将明文的报文转成二进制,而是直接解析二进制报文,这增加了数据传输的效率
  • 并发传输:引出了 Stream 概念,多个 Stream 复用在一条 TCP 连接。解决了HTTP/1.1 队头阻塞的问题:
  • 服务器主动推送资源:HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式,服务端不再是被动地响应,可以主动向客户端发送消息。

14、HTTP进行TCP连接之后,在什么情况下会中断

  • 当服务端或者客户端执行 close 系统调用的时候,会发送FIN报文,就会进行四次挥手的过程
  • 当发送方发送了数据之后,接收方超过一段时间没有响应ACK报文,发送方重传数据达到最大次数的时候,就会断开TCP连接
  • 当HTTP长时间没有进行请求和响应的时候,超过一定的时间,就会释放连接

15、DNS 域名解析的工作流程?

  1. 客户端首先会发出一个 DNS 请求,问 www.server.com 的 IP 是啥,并发给本地 DNS 服务器(也就是客户端的 TCP/IP 设置中填写的 DNS 服务器地址)。
  2. 本地域名服务器收到客户端的请求后,如果缓存里的表格能找到 www.server.com,则它直接返回 IP 地址。如果没有,本地 DNS 会去问它的根域名服务器:“老大, 能告诉我 www.server.com 的 IP 地址吗?” 根域名服务器是最高层次的,它不直接用于域名解析,但能指明一条道路。
  3. 根 DNS 收到来自本地 DNS 的请求后,发现后置是 .com,说:“www.server.com 这个域名归 .com 区域管理”,我给你 .com 顶级域名服务器地址给你,你去问问它吧。”
  4. 本地 DNS 收到顶级域名服务器的地址后,发起请求问“老二, 你能告诉我 www.server.com 的 IP 地址吗?”
  5. 顶级域名服务器说:“我给你负责 www.server.com 区域的权威 DNS 服务器的地址,你去问它应该能问到”。
  6. 本地 DNS 于是转向问权威 DNS 服务器:“老三,www.server.com对应的IP是啥呀?” server.com 的权威 DNS 服务器,它是域名解析结果的原出处。为啥叫权威呢?就是我的域名我做主。
  7. 权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
  8. 本地 DNS 再将 IP 地址返回客户端,客户端和目标建立连接。

至此,我们完成了 DNS 的解析过程。现在总结一下,整个过程我画成了一个图。

img

16、DNS的底层使用TCP还是UDP?

DNS 基于UDP协议实现,DNS使用UDP协议进行域名解析和数据传输。因为基于UDP实现DNS能够提供低延迟、简单快速、轻量级的特性,更适合DNS这种需要快速响应的域名解析服务。

  • 低延迟:  UDP是一种无连接的协议,不需要在数据传输前建立连接,因此可以减少传输时延,适合DNS这种需要快速响应的应用场景。
  • 简单快速:  UDP相比于TCP更简单,没有TCP的连接管理和流量控制机制,传输效率更高,适合DNS这种需要快速传输数据的场景。
  • 轻量级:UDP头部较小,占用较少的网络资源,对于小型请求和响应来说更加轻量级,适合DNS这种频繁且短小的数据交换。

尽管 UDP 存在丢包和数据包损坏的风险,但在 DNS 的设计中,这些风险是可以被容忍的。DNS 使用了一些机制来提高可靠性,例如查询超时重传、请求重试、缓存等,以确保数据传输的可靠性和正确性。

17、HTTP到底是不是无状态的?

HTTP是无状态的,这意味着每个请求都是独立的,服务器不会在多个请求之间保留关于客户端状态的信息。在每个HTTP请求中,服务器不会记住之前的请求或会话状态,因此每个请求都是相互独立的。

虽然HTTP本身是无状态的,但可以通过一些机制来实现状态保持,其中最常见的方式是使用Cookie和Session来跟踪用户状态。通过在客户端存储会话信息或状态信息,服务器可以识别和跟踪特定用户的状态,以提供一定程度的状态保持功能。

18、携带Cookie的HTTP请求是有状态还是无状态的?Cookie是HTTP协议簇的一部分,那为什么还说HTTP是无状态的?

携带Cookie的HTTP请求实际上是可以在一定程度上实现状态保持的,因为Cookie是用来在客户端存储会话信息和状态信息的一种机制。当浏览器发送包含Cookie的HTTP请求时,服务器可以通过读取这些Cookie来识别用户、管理会话状态以及保持特定的用户状态。因此,可以说即使HTTP本身是无状态的协议,但通过Cookie的使用可以实现一定程度的状态保持功能。

HTTP被描述为“无状态”的主要原因是每个HTTP请求都是独立的,服务器并不保存关于客户端的状态信息,每个请求都需要提供足够的信息来理解请求的意图。这样的设计使得Web系统更具有规模化和简单性,但也导致了一些挑战,比如需要额外的机制来处理用户状态和会话管理。

虽然Cookie是HTTP协议簇的一部分,但是HTTP协议在设计初衷上仍然保持无状态特性,即每个请求都是相互独立的。使用Cookie只是在无状态协议下的一种补充机制,用于在客户端存储状态信息以实现状态保持。

19、cookie和session有什么区别?

Cookie和Session都是Web开发中用于跟踪用户状态的技术,但它们在存储位置、数据容量、安全性以及生命周期等方面存在显著差异:

  • 存储位置:Cookie的数据存储在客户端(通常是浏览器)。当浏览器向服务器发送请求时,会自动附带Cookie中的数据。Session的数据存储在服务器端。服务器为每个用户分配一个唯一的Session ID,这个ID通常通过Cookie或URL重写的方式发送给客户端,客户端后续的请求会带上这个Session ID,服务器根据ID查找对应的Session数据。
  • 数据容量:单个Cookie的大小限制通常在4KB左右,而且大多数浏览器对每个域名的总Cookie数量也有限制。由于Session存储在服务器上,理论上不受数据大小的限制,主要受限于服务器的内存大小。
  • 安全性:Cookie相对不安全,因为数据存储在客户端,容易受到XSS(跨站脚本攻击)的威胁。不过,可以通过设置HttpOnly属性来防止JavaScript访问,减少XSS攻击的风险,但仍然可能受到CSRF(跨站请求伪造)的攻击。Session通常认为比Cookie更安全,因为敏感数据存储在服务器端。但仍然需要防范Session劫持(通过获取他人的Session ID)和会话固定攻击。
  • 生命周期:Cookie可以设置过期时间,过期后自动删除。也可以设置为会话Cookie,即浏览器关闭时自动删除。Session在默认情况下,当用户关闭浏览器时,Session结束。但服务器也可以设置Session的超时时间,超过这个时间未活动,Session也会失效。
  • 性能:使用Cookie时,因为数据随每个请求发送到服务器,可能会影响网络传输效率,尤其是在Cookie数据较大时。使用Session时,因为数据存储在服务器端,每次请求都需要查询服务器上的Session数据,这可能会增加服务器的负载,特别是在高并发场景下。

20、token,session,cookie的区别?

  • session存储于服务器,可以理解为一个状态列表,拥有一个唯一识别符号sessionId,通常存放于cookie中。服务器收到cookie后解析出sessionId,再去session列表中查找,才能找到相应session,依赖cookie。
  • cookie类似一个令牌,装有sessionId,存储在客户端,浏览器通常会自动添加。
  • token也类似一个令牌,无状态,用户信息都被加密到token中,服务器收到token后解密就可知道是哪个用户,需要开发者手动添加。

21、如果客户端禁用了cookie,session还能用吗?

默认情况下禁用 Cookie 后,Session 是无法正常使用的,因为大多数 Web 服务器都是依赖于 Cookie 来传递 Session 的会话 ID 的。

客户端浏览器禁用 Cookie 时,服务器将无法把会话 ID 发送给客户端,客户端也无法在后续请求中携带会话 ID 返回给服务器,从而导致服务器无法识别用户会话。

但是,有几种方法可以绕过这个问题,尽管它们可能会引入额外的复杂性和/或降低用户体验。