【面经】字节跳动Java后端开发

最新推荐文章于 2024-10-16 16:34:42 发布

爱写代码的July

最新推荐文章于 2024-10-16 16:34:42 发布

阅读量1.4k

点赞数 9

分类专栏：面经分享文章标签： java 开发语言网络网络协议计算机网络决策树 b树

本文链接：https://blog.csdn.net/Liu_y_xin/article/details/141904433

版权

面经分享专栏收录该内容

37 篇文章 0 订阅

订阅专栏

一包装类Integer，如果值都是100，用==判断，它们是否是相等的？

在 Java 中，Integer 包装类有一个常量池范围为 -128 到 127。对于这个范围内的 Integer 对象，Java 会进行缓存，== 比较的是引用。因此，如果值是 100（在缓存范围内），== 判断会返回 true，因为它们指向的是同一个对象。超出该范围的值则会返回 false。

二 StringBuilder默认容量，扩容机制？

StringBuilder 的默认初始容量为 16。当 StringBuilder 需要扩容时，它会按照：新容量 = (旧容量 × 2) + 2的规则进行扩容。

三 String的底层数据结构是什么，和C语言实现的有什么区别？

String 在 Java 中是通过一个 char[] 数组存储的，且是不可变的，一旦创建了 String 对象，它的值就不能改变。在 C 语言中，字符串是以 char* 指针存储的，通常以 null（'\0'）结尾，且是可变的（不安全）。C 语言没有自动管理字符串的内存，容易引发缓冲区溢出和内存泄漏问题。

四 SDS如何获取字符串的长度？

SDS (Simple Dynamic String) 是 Redis 的字符串实现，使用预分配的方式来管理内存。SDS 的长度不是通过遍历字符串来获取的，而是通过一个额外的字段存储字符串长度。这样可以在 O(1) 的时间复杂度内获得字符串的长度。

五 RDB和AOF持久化机制，两者对比，什么时候用AOF？

RDB 通过快照的方式将 Redis 内存中的数据定时写入磁盘。其优点是数据文件紧凑、存储效率高，恢复速度快。缺点是可能会丢失最近一次快照之后的数据。

AOF 记录每一个写操作，将命令追加到日志文件中。优点是数据持久化更为可靠，几乎可以做到实时同步。缺点是 AOF 文件会随着时间增大，恢复速度较慢。

当对数据安全性要求高，不能容忍数据丢失时（例如金融、重要的交易数据），建议使用 AOF。

六 mysql持久化机制？

Redo Log（重做日志）: 用于保障事务提交后，即使服务器崩溃，数据也不会丢失。它是物理日志，记录页面的修改。

Binlog（二进制日志）: 用于记录所有写操作的日志，支持数据恢复和主从同步。Binlog 是逻辑日志，记录的是 SQL 语句。

七 mysql如何保证事务的一致性？

一致性是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。 MySQL通过内部一致性机制（如外键约束）保证。

八 mysql索引的数据结构？

MySQL 中的主流存储引擎 InnoDB 使用B+ 树作为索引的数据结构。B+ 树是一种平衡的多路搜索树，其所有的值都存储在叶子节点，非叶子节点只存储键值，且叶子节点通过链表相连，方便范围查询。

九为什么要用B+树，而不是B树、红黑树？

因为B树不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低；

Hash虽然可以快速定位，但是没有顺序，IO复杂度高。

二叉树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且IO代价高。

红黑树的高度随着数据量增加而增加，IO代价高。

十一颗B+树最多可存储几条记录，到几层的时候就无法接受，随着层数增加性能变差的原因？

设 B+ 树的阶数为 m，单个节点可以存储 m-1 个键。由于 B+ 树是平衡的，深度为 h 的 B+ 树可以存储的最大记录数为 mh−1m^{h-1}mh−1。随着节点容量的增加，记录数也随之增加。

B+ 树层数的增加会导致访问叶子节点的磁盘 IO 次数增加，尤其在大规模数据存储时，层数越高，访问速度越慢。因此，通常 B+ 树的层数控制在 3-5 层较为合适。

十一 HTTP1.0和HTTP1.1的区别？

长连接：HTTP 1.1支持长连接（Persistent Connection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略，可供选择的缓存头来控制缓存策略。

带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

错误通知的管理：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。