（高频问题）261-280 计算机 Java后端 实习 and 秋招 面试高频问题汇总

专栏简介

261. 跳表相较于红黑树的核心优势分析

跳表与红黑树在特定场景下各有优势。跳表的一项显著优势在于其实现的简洁性。它主要依赖链表结构和随机化技术来构建多层索引，代码逻辑相对直接，易于理解和维护，尤其在插入和删除操作时，不需要像红黑树那样进行复杂的平衡调整，如旋转或重新着色。

尽管红黑树这类平衡树也具备 O(log N) 的时间复杂度，但其维持平衡的机制较为复杂。插入和删除操作可能触发多次旋转和颜色调整，这不仅增加了代码的实现难度，也使得调试和维护更具挑战性。

在空间使用和访问特性方面，跳表的空间复杂度可能略高于红黑树，但它能够灵活调整层数以适应不同的查询和插入模式。更重要的是，跳表的结构天然支持高效的顺序访问和范围查询。一旦定位到范围的起始点，即可通过最底层的链表以 O(K) 的时间复杂度（K为访问元素数量）进行快速遍历，这在处理大规模顺序数据时表现优异。

并发控制是跳表的另一大优势。由于其多层链表的本质，跳表更容易实现高并发环境下的细粒度锁控制，例如通过分层锁或对链表节点进行精细锁定。相比之下，红黑树的旋转操作可能涉及树的较大范围结构调整，实现高效并发控制的难度更高，往往需要更复杂的锁策略。

262. Lua脚本在Redis单机与集群环境下的关键差异

Lua脚本在Redis单机实例和集群环境下的运作机制存在显著差异，主要体现在数据访问范围、键操作限制以及原子性保障层面。

在单机Redis中，Lua脚本的执行是原子性的，并且可以访问该Redis实例内的所有数据，不受任何节点或分片限制。脚本执行期间，Redis服务器不会交错执行其他命令，从而确保了操作的完整性和一致性。

然而，在Redis集群模式下，Lua脚本的执行范围受到严格限制，即脚本只能在单个节点上执行。这意味着脚本内部操作的所有键都必须位于同一个哈希槽（hash slot）中，也就是由同一个节点管理。如果脚本尝试访问分布在不同节点上的键，操作将会失败。为了确保多个键能被同一个脚本处理，开发者需要使用哈希标签（hash tags），例如将键名设计为{user:1000}:name和{user:1000}:email，这样Redis集群会根据花括号内的部分（即user:1000）计算哈希槽，保证它们落在同一节点。Redis集群共有16384个哈希槽。

关于原子性，虽然Lua脚本在集群的单个节点上的执行依然保持原子性，但无法通过单个Lua脚本来保证跨多个节点操作的原子性。对于涉及多节点的数据一致性需求，需要在客户端层面进行协调和管理。此外，在集群环境中，Lua脚本需要在每个节点上分别进行加载和管理，并不存在全局的脚本共享或传播机制。

263. 两阶段提交（2PC）与三阶段提交（3PC）的核心差异及3PC的优势

两阶段提交（2PC）和三阶段提交（3PC）是分布式系统中用于保障分布式事务原子性和一致性的重要协议。它们的核心差异主要体现在协议阶段的设计以及故障处理能力上。

2PC包含两个核心阶段：

1. 准备阶段（Prepare Phase）：协调者向所有参与者发送准备请求。参与者执行事务操作，记录日志，但不实际提交，并向协调者返回“准备就绪”或“失败”的响应。
2. 提交阶段（Commit Phase）：如果所有参与者均回复“准备就绪”，协调者则发送提交请求，参与者执行提交；若有任何参与者失败或超时，协调者发送回滚请求，参与者执行回滚。

3PC则引入了额外的阶段，细化了提交流程：

1. 可提交阶段（CanCommit Phase）：协调者询问参与者是否可以执行事务。参与者检查自身资源和状态，回复“是”或“否”。
2. 预提交阶段（PreCommit Phase）：若所有参与者均回复“是”，协调者发送预提交请求。参与者执行事务操作，记录日志，并进入“预备提交”状态，等待最终指令。
3. 提交阶段（DoCommit Phase）：协调者根据预提交阶段的反馈（或超时情况）发送提交或中止请求。参与者完成最终提交或回滚。

3PC相较于2PC的主要优势在于其改进的故障处理机制和减少的阻塞可能性。在2PC中，若协调者在发送提交请求后、所有参与者确认前发生故障，或者协调者与某些参与者之间网络分区，参与者会因无法确定最终状态而陷入阻塞。3PC通过增加CanCommit和PreCommit阶段，特别是PreCommit阶段，引入了超时机制。如果在PreCommit阶段后协调者故障或参与者未收到DoCommit指令，参与者在超时后可以自行决定提交（如果进入了PreCommit状态）或中止事务，从而降低了系统长时间阻塞的风险，提高了系统的可用性和容错性。增加一个阶段主要是为了在协调者和参与者之间建立一个更明确的“意向”状态，减少不确定性。

264. 2PC、3PC与Raft协议在分布式一致性保障中的应用场景差异

2PC、3PC和Raft协议虽然都服务于分布式系统的一致性保障，但它们解决的问题范畴和适用的具体场景有所不同。

2PC和3PC主要关注于分布式事务的原子性，确保跨多个独立资源（如数据库、消息队列）的操作能够作为一个整体，要么全部成功执行，要么全部失败回滚。这种场景通常被称为垂直的事务一致性，强调的是一个事务在其生命周期内跨越不同阶段和操作时，所有步骤的最终结果必须一致。例如，在涉及多个数据库更新的银行转账业务中，2PC被广泛应用以保证资金从一个账户扣除与另一个账户增加这两个操作的一致性。3PC作为2PC的改进，通过增加一个预备阶段来减少协调者故障时参与者的阻塞时间，适用于对系统可用性和容错性有更高要求的环境。

Raft协议则是一种分布式共识算法，其核心目标是让一组服务器（节点）就某个值或一系列状态（通常是日志条目）达成一致。它解决的是水平的节点共识问题，即在任何给定时间点，确保系统中的多个副本或节点对于某一共享状态的认知保持一致，即使在部分节点发生故障或网络分区的情况下，系统仍能通过多数派原则继续安全运行。Raft的应用场景包括分布式系统的Leader选举、日志复制、状态机复制以及高可用的配置管理服务等。例如，在分布式数据库或键值存储中，Raft常被用来确保数据在多个副本间的一致性复制和故障切换。

265. 连接池中潜在的数据串流风险及防范措施

数据库连接池在设计上致力于通过复用连接来提升性能，并通常能够有效隔离不同请求对连接的使用。然而，如果连接池的管理或应用程序对连接的使用方式不当，确实存在潜在的数据串流风险，即一个线程或请求错误地读取或修改了属于另一个线程或请求的数据。

这类问题通常源于以下几种情况：其一是连接未被正确关闭或归还到池中，导致连接上可能残留了前一个操作的状态（如未提交的事务、会话变量等），当该连接被下一个请求复用时，可能发生数据混淆。其二是应用程序手动管理事务（例如，设置setAutoCommit(false)）但未能确保每个事务都正确提交或回滚，使得一个未结束的事务状态影响了后续使用该连接的操作。

为有效防范数据串流等连接使用问题，应采取以下关键措施：

务必确保每次数据库操作完成后，连接都得到妥善关闭或释放回池中。在Java等语言中，推荐使用try-with-resources语句，或者在finally块中执行关闭操作，以保证连接在任何情况下（包括异常发生时）都能被正确处理。对于事务管理，应确保事务的边界清晰，并在操作完成后显式提交（commit）或回滚（rollback）。避免将处于未决事务状态的连接归还给连接池。

应尽量缩短持有连接的时间，在获取连接后迅速完成数据库交互并立即释放，避免在持有连接的状态下执行耗时的业务逻辑。选择并使用经过广泛验证的、成熟的连接池实现（例如HikariCP、Druid、C3P0等），这些连接池通常内置了更完善的连接状态清理和管理机制。

此外，合理配置连接池参数，并对连接池的运行状态进行持续监控，有助于及时发现和定位潜在的连接使用不当问题。

266. PCB中父子进程关系的维护机制

进程控制块 (PCB) 是操作系统用于管理进程的核心数据结构。父子进程关系主要通过PCB中的特定字段来维护。

每个进程在其PCB中都存储有自身的进程ID (PID)以及其父进程的ID (PPID)。通过PPID，任何进程都可以明确其父进程，这是建立父子关系的基础。

此外，许多操作系统的PCB设计中，会包含一个指向子进程列表的指针或数据结构。该列表汇集了由当前进程创建的所有子进程的PCB引用，使得操作系统能够高效地遍历和管理特定父进程下的所有子进程。部分实现中，PCB内也可能直接包含一个**parent指针**，直接指向其父进程的PCB，进一步巩固这种层级关系。这些机制共同确保了操作系统能够清晰地追踪和管理进程间的亲缘关系。

267. 多线程环境下通过锁与条件变量实现交替打印123

题目要求启动三个独立的线程，分别负责循环打印数字1、2、3，并确保它们的输出顺序严格按照123123...的模式进行。

核心实现思路是利用一个共享变量（globalNumber）来控制当前应由哪个线程执行打印操作，并结合**锁（lock）以及条件变量机制（wait() 和 notifyAll()）**进行线程间的同步与协作。

每个线程在进入打印逻辑前首先获取锁。在synchronized代码块中，线程会检查共享变量globalNumber是否等于自身需要打印的数字。若不等于，则调用lock.wait()方法，释放锁并进入等待状态。当其他线程完成打印并修改globalNumber后，会调用lock.notifyAll()唤醒所有等待的线程。

被唤醒的线程会重新竞争锁，并再次检查条件。只有当条件满足时（globalNumber等于其目标数字），线程才会执行打印操作，然后更新globalNumber为下一个应打印的数字（例如，从1到2，从2到3，从3回到1），并再次调用lock.notifyAll()通知其他线程。

import java.util.*;
import java.lang.*;

public class Main {

    private final Object lock = new Object();
    private volatile int globalNumber = 1; // 共享变量，控制打印顺序

    public static void main(String[] args) {
        Main main = new Main();
        Thread t1 = new Thread(() -> {
            main.printNumber(1); // 线程1打印数字1
        });
        Thread t2 = new Thread(() -> {
            main.printNumber(2); // 线程2打印数字2
        });
        Thread t3 = new Thread(() -> {
            main.printNumber(3); // 线程3打印数字3
        });
        t1.start();
        t2.start();
        t3.start();
    }

    public void printNumber(int threadNum) {
        // 为了演示，这里设置为循环10次，实际题目要求无限循环，可以将 for 循环改为 while(true)
        for (int i = 0; i < 10; i++) { 
            synchronized (lock) {
                // 当全局数字不等于当前线程应打印的数字时，线程等待
                while (globalNumber != threadNum) {
                    try {
                        lock.wait(); // 释放锁并进入等待状态
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt(); // 重置中断状态
                        return;
                    }
                }
                // 条件满足，执行打印
                System.out.println(threadNum);
                // 更新全局数字，指向下一个应打印的数字
                globalNumber = (globalNumber % 3) + 1; 
                lock.notifyAll(); // 唤醒所有等待在该锁上的线程
            }
        }
    }
}

值得注意的是，while (globalNumber != threadNum) 循环结合 lock.wait()并非忙等待（busy-waiting）。当条件不满足时，线程通过 wait()释放锁并进入休眠状态，等待被其他线程通过 notifyAll() 唤醒。唤醒后，线程会再次检查条件，只有满足时才继续执行，否则再次等待，从而有效避免了CPU资源的空转。

268. Kafka实现高吞吐量的关键技术解析

Kafka 实现卓越的吞吐量得益于多项精心设计的关键技术。

首先，它充分利用了顺序磁盘写入的特性。数据以追加（append-only）方式写入磁盘上的日志文件，这种方式避免了机械硬盘磁头的频繁随机寻道，其性能远快于随机写入，甚至接近内存的写入速度。

其次，Kafka 是一个分布式架构。消息数据可以分散存储在多个 Broker 节点上，并且每个主题（Topic）可以划分为多个分区（Partition）。这种设计使得读写负载能够均衡地分布到集群中的各个节点和分区，从而实现水平扩展和并行处理，大幅提升整体处理能力。

数据传输效率方面，Kafka 采用了零拷贝（Zero-copy）技术。在数据从磁盘发送到网络接口（NIC）的过程中，通过操作系统的支持，数据可以直接在内核空间进行传输，避免了在用户空间和内核空间之间的多次数据拷贝，显著降低了CPU开销和上下文切换的延迟。

此外，Kafka 支持消息的批量处理。生产者可以将多条消息累积成一个批次（batch）后一次性发送给Broker，消费者也可以批量从Broker拉取消息。这种机制减少了网络请求次数和I/O操作的频率，分摊了单条消息的处理开销。结合高效的自定义二进制网络通信协议和可选的消息压缩功能（如Snappy, Gzip, LZ4），进一步减少了网络传输的数据量和序列化/反序列化开销，共同构成了Kafka高吞吐量的坚实基础。

269. Web浏览器如何确定未指定端口号的服务器目标端口

当用户在浏览器中输入网址（例如 www.taobao.com）且未显式指定端口号时，浏览器会依据URL中的协议类型自动使用该协议的默认端口号。

对于 HTTP 协议，其默认端口是 80。因此，访问 http://www.taobao.com 时，浏览器会尝试连接淘宝服务器的80端口。对于 HTTPS 协议（安全的HTTP），其默认端口是 443。因此，访问 https://www.taobao.com 时，浏览器会尝试连接淘宝服务器的443端口。

域名系统 (DNS) 的核心职责是将用户易于记忆的域名解析为服务器的IP地址。它通常不直接参与端口号的解析（SRV记录是一种例外情况，允许服务发现包含端口信息，但浏览器在常规网页访问中较少依赖此机制）。浏览器在通过DNS获取到IP地址后，便会结合协议类型使用上述默认端口与服务器建立连接。

如果服务器端的应用程序实际监听的是一个非标准端口（例如，一个Java Web应用可能部署在8080端口），为了让用户能够通过标准的80或443端口（即不带端口号的URL）访问，通常会配置一个反向代理服务器（如 Nginx 或 Apache HTTP Server）。这个反向代理服务器会监听公共的80或443端口，接收到用户的请求后，再将这些请求透明地转发到内部应用实际监听的非标准端口上。

270. HTTPS客户端验证与信任服务器证书的机制

HTTPS客户端（通常是浏览器或操作系统级别的网络库）信任服务器SSL/TLS证书的机制是建立在一个预先建立的信任体系之上的。

其核心在于客户端内置了一组受信任的根证书颁发机构（Root Certificate Authorities, Root CAs）的公共证书。这些根CA是全球公认的、经过严格审核的可信实体，其根证书在操作系统或浏览器安装时就已经预置。

当客户端尝试与一个