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

专栏简介

81.Java对象实例化与类加载详解

Java对象的创建流程

在Java虚拟机（JVM）中，使用new关键字创建对象实例遵循一个明确的流程。首先，JVM会进行类加载检查，确认目标类的符号引用是否存在于常量池中，并且该类是否已经被加载、解析及初始化。若类尚未加载，则必须先触发相应的类加载过程。

类加载完成后，JVM会为新对象分配内存。所需内存的大小在类加载阶段就已经确定。内存分配主要有两种策略：“指针碰撞”（适用于连续规整的堆内存，通过移动分配指针来划分区域）和“空闲列表”（适用于非规整的堆内存，通过维护列表来查找足够大的空闲块）。内存分配完毕后，JVM会将分配到的内存空间（不含对象头）初始化为零值。这一步确保了对象的实例字段无需显式初始化即可拥有默认值（如0, null, false）。

接下来，JVM会设置对象头，存储对象的元数据信息，例如对象的类信息、哈希码、GC分代年龄等。最后，JVM执行对象的<init>构造方法，按照Java代码中定义的逻辑进行实例变量的初始化和其它构造逻辑。至此，一个完整的对象实例才算创建成功。

Java类加载机制

类加载是Java程序运行的基础，它负责将类的.class文件加载到内存，并转换为运行时数据结构。该过程主要包括以下阶段：

1. 加载（Loading）：JVM通过类的全限定名找到对应的.class文件，读取其二进制字节流，并将其转换为方法区中的运行时数据结构。同时，在Java堆中生成一个java.lang.Class对象，作为访问方法区类数据的入口。
2. 验证（Verification）：确保加载的类信息符合JVM规范，并且没有安全隐患，保证其不会危害虚拟机自身的安全。
3. 准备（Preparation）：为类的静态变量（类变量）分配内存，并设置其初始零值。这些内存通常分配在方法区。
4. 解析（Resolution）：将常量池内的符号引用（如类、方法、字段的名称）替换为直接引用（内存地址或偏移量）。
5. 初始化（Initialization）：执行类的<clinit>()方法。该方法由编译器收集类中所有静态变量的赋值语句和静态代码块合并而成。JVM保证<clinit>()方法在多线程环境下的正确同步。

对象实例化必须发生在类加载完成之后，类加载为对象的创建提供了必要的基础信息和运行时结构。

82.代码编译流程详解与静态链接机制

源代码到可执行文件的编译流程

将人类可读的源代码转换为机器可执行代码的编译过程，通常包含以下几个核心阶段：

• 预处理（Preprocessing）：编译器首先处理源代码中的预处理指令，如#include（文件包含）、#define（宏替换）、#ifdef（条件编译）等。此阶段输出的是一个移除了预处理指令、展开了宏、包含了头文件内容的“纯净”源代码文件。
• 词法分析（Lexical Analysis）：词法分析器（扫描器）读取预处理后的代码，将其分解为一系列称为“标记”（Token）的最小语法单元，例如关键字、标识符、常量、运算符等。输出是一个标记序列。
• 语法分析（Syntax Analysis）：语法分析器（解析器）根据语言的语法规则，将标记序列组合成抽象语法树（Abstract Syntax Tree, AST）。AST是源代码结构的树状表示，反映了代码的语法层级关系。
• 语义分析（Semantic Analysis）：此阶段检查AST中的语义错误，如类型不匹配、变量未声明等。它会收集类型信息，进行类型检查，并注解AST，为后续代码生成做准备。
• 中间代码生成（Intermediate Code Generation）：编译器将经过语义分析的AST转换为一种与源语言和目标机器都相对独立的中间表示（Intermediate Representation, IR）。IR简化了后续的优化和代码生成过程。
• 优化（Optimization）：优化器分析并转换中间代码，目的是提高生成代码的运行效率或减少资源消耗。优化可能包括常量折叠、循环展开、死代码删除等多种技术，可在不同层级进行。
• 代码生成（Code Generation）：最后，代码生成器将优化后的中间代码转换为目标机器的机器语言（汇编代码或直接的机器码）。这包括指令选择、寄存器分配等步骤。输出通常是目标文件（Object File）。

静态链接的时机与作用

静态链接发生在编译过程的最后阶段，具体是在生成了各个源文件的目标代码之后、创建最终可执行文件之前。链接器（Linker）负责将程序引用的多个目标文件以及所需的库文件（包含预编译的目标代码）合并成一个单一的、完整的可执行文件。

静态链接的主要特点包括：生成的可执行文件包含了所有依赖的代码和库，因此具有良好的独立性，可以在没有相应库文件的系统上运行。由于代码在链接时就已经确定地址，可能带来启动速度上的优势。然而，缺点是可执行文件体积通常较大，且如果库更新（如修复漏洞），必须重新编译链接整个应用程序才能应用更新。

83.在UDP协议基础上实现可靠传输的策略

UDP（用户数据报协议）本身是一种无连接、不可靠的传输层协议，它不保证数据包的顺序、不丢失或不重复。然而，若应用层需要基于UDP实现可靠的数据传输，可以通过在应用程序中实现以下机制来弥补UDP的不足：

• 确认与超时重传机制：发送方为每个发出的数据包启动一个定时器。接收方收到数据包后，发送一个确认（ACK）回报给发送方。如果发送方在定时器超时前未收到ACK，则认为数据包丢失，并重新发送该数据包。
• 序列号机制：为每个数据包分配一个唯一的、递增的序列号。接收方利用序列号来检测丢失的数据包（序号不连续）和重复的数据包（收到已确认过的序号），并能够按正确的顺序重组数据。
• 滑动窗口协议：为了提高传输效率，可以引入滑动窗口。发送方维护一个发送窗口，允许在收到确认前连续发送多个数据包。接收方也维护一个接收窗口，用于流量控制和缓冲失序到达的数据包。这显著减少了因等待ACK而产生的延迟。
• 错误检测与纠正：虽然UDP头部自带校验和用于基本的错误检测，但应用层可以实现更强的错误检测机制（如CRC）或前向纠错（FEC）编码。FEC允许接收方在一定程度上恢复损坏的数据，而无需重传。
• 流量控制：接收方可以通过某种机制（如在ACK中携带窗口大小信息）告知发送方其当前的接收能力，防止发送方发送过快导致接收方缓冲区溢出而丢包。
• 多路径传输：在可能的情况下，将数据分散到多个网络路径上进行传输，可以提高整体的鲁棒性，即使某条路径出现问题，数据仍有可能通过其他路径成功到达。

实现这些可靠性机制会增加应用程序的复杂度和开发成本。因此，在选择UDP并自行实现可靠性之前，应仔细评估应用场景的需求（如对延迟、吞吐量、可靠性的要求）以及与直接使用TCP等原生支持可靠传输协议的利弊。对于实时音视频、在线游戏等对延迟敏感的应用，基于UDP定制可靠性策略可能是更优的选择。

84.MySQL事务原子性保障：锁与Undo Log机制，及Redo/Binlog对比

事务原子性的实现：锁与Undo Log协同工作

确保数据库事务的原子性（Atomicity）——即事务内的所有操作要么全部成功提交，要么全部失败回滚——并不仅仅依赖于锁机制。锁（Locking）和Undo日志（Undo Log）共同保障了原子性。

• 锁（Locking）：主要作用是管理并发事务对共享资源的访问，防止数据竞争和不一致。通过行锁、表锁等机制，锁确保了事务在执行过程中的隔离性，即一个事务的中间状态对其他事务是不可见的（取决于隔离级别）。虽然锁对于并发控制至关重要，但它本身不直接负责失败时的回滚操作。
• Undo日志（Undo Log）：是实现原子性的核心机制。它记录了事务执行过程中对数据的修改前的状态。如果事务执行过程中发生错误，或者用户显式执行ROLLBACK，MySQL可以利用Undo日志中的信息撤销已经执行的操作，将数据恢复到事务开始之前的状态，从而保证了事务的“要么全做，要么全不做”的原子性特性。

简而言之，锁主要保障并发事务执行的隔离性，而Undo日志则提供了事务失败或回滚时恢复数据的能力，两者结合共同确保了事务的原子性。

Redo Log与Binlog的关键区别

MySQL中存在两种重要的日志：Redo Log和Binlog，它们在功能、层级和工作方式上存在显著差异：

1. 主要目的： Redo Log（重做日志）：属于InnoDB存储引擎层的日志，核心目的是保证事务的持久性（Durability）。它记录了事务对数据页所做的物理修改。即使在事务提交后数据库崩溃，InnoDB也可以通过Redo Log重放这些修改，恢复已提交但尚未完全写入磁盘数据文件的数据，确保数据不丢失。Binlog（二进制日志）：属于MySQL服务器层的日志，对所有存储引擎都有效。主要用于数据复制（主从同步）和基于时间点的数据恢复。它记录了所有修改数据库状态的逻辑操作（如SQL语句或基于行的变更）。
2. 记录内容与格式： Redo Log：通常记录的是物理操作日志，即对哪个数据页的哪个偏移量做了什么修改，内容紧凑，恢复速度快。它是固定大小、循环写入的。Binlog：记录的是逻辑操作日志（有Statement、Row、Mixed三种格式），更易于人类阅读和理解。它是追加写入的，文件达到一定大小后会滚动生成新文件。
3. 写入时机： Undo Log：在执行SQL修改操作之前写入，记录如何撤销。Redo Log：在事务执行过程中持续写入，在事务提交前必须完成持久化（至少是写入日志缓冲区并可能刷盘），这是保证持久性的关键步骤（Write-Ahead Logging, WAL）。Binlog：在事务提交完成之后写入。MySQL通过两阶段提交（2PC）协调Redo Log和Binlog的写入，确保两者状态一致。

总结来说，Redo Log保障InnoDB事务的持久性，Binlog服务于复制和恢复；Redo Log是物理日志，Binlog是逻辑日志；Redo Log是InnoDB特有，Binlog是Server层通用。Undo Log则专注于事务回滚，保障原子性。这三者共同构成了MySQL事务处理和数据可靠性的重要基石。

Redo Log

Redo Log主要用于保证事务的持久性，是InnoDB存储引擎特有的日志文件。Redo Log记录了事务执行过程中对数据库做的修改操作，但这些修改可能还没有被持久化到磁盘的数据文件中。

• 用途：主要用于崩溃恢复。如果数据库发生故障，使用Redo Log可以将内存中的但未写入磁盘的数据重做，确保这些数据不会丢失。
• 工作方式：采用循环写入的方式，空间固定。当日志空间被填满后，旧的记录会被新的记录覆盖。
• 与事务处理的关系：紧密相关。Redo Log是事务提交的一部分，确保事务的持久性。

Binlog

Binlog，即存储格式是二进制，是MySQL服务器层（而不是存储引擎层）的日志文件，记录了所有修改了数据库数据的SQL语句（DDL和DML，但不包括SELECT和SHOW这类的操作）。

• 用途：主要用于数据复制和数据恢复。通过Binlog，可以在主从复制场景中将数据变更同步到从服务器，或者在数据丢失后用于数据恢复。
• 工作方式：追加写入。新的变更被追加到日志文件的末尾，当文件达到一定大小后，会创建新的日志文件继续写入。
• 与事务处理的关系：相对松散。Binlog写入通常在事务提交后进行，用于记录事务所做的修改，以便于复制或恢复数据。

主要区别

1. 目的不同：Redo Log用于崩溃恢复，保证事务的持久性；Binlog用于数据复制和恢复，确保数据的一致性和完整性。
2. 层级不同：Redo Log是InnoDB存储引擎特有的，工作在存储引擎层；而Binlog工作在MySQL服务器层，对所有存储引擎有效。
3. 记录内容不同：Redo Log记录的是物理日志，即对页的物理修改操作；Binlog记录的是逻辑日志，即SQL语句。
4. 写入时机不同：Redo Log在事务进行中不断写入，是事务提交的一部分；Binlog在事务提交后写入。
5. 格式不同：Redo Log是固定大小且循环写入的，Binlog是追加写入，当文件大小达到一定值后会创建新文件继续写入。

Binlog的写入时机是在事务提交之后。具体来说，当一个事务在MySQL中执行时，操作会先在InnoDB的内存缓冲区中进行，事务提交时会将修改后的数据页刷新到磁盘，并在这个时候将事务的变化记录到Binlog中。

在MySQL中，Redo Log是在事务提交前写入的，它通过记录数据页的物理修改来确保数据的持久性和一致性。相比之下，Binlog是在事务提交后写入的，用于记录事务的逻辑变化，主要用于数据复制和恢复

• Undo Log 是在执行 SQL 操作之前写入的，用于记录如何撤销这次操作，主要用于事务的回滚。
• Redo Log 是在事务进行修改操作时几乎同时写入的，但关键的持久化到磁盘的动作是在事务提交前发生，用于记录如何重做这次操作，主要用于恢复提交的事务。

因此，Undo Log 和 Redo Log 都是在 SQL 操作执行的过程中被写入的，但它们的具体写入时机和目的存在差别，共同保证了数据库事务的ACID属性。

85.MySQL索引结构选择：B+树与红黑树的比较及内存数据库适用性

MySQL索引为何优选B+树

MySQL中最常用的存储引擎InnoDB默认使用B+树作为其索引的数据结构。选择B+树而非像红黑树这样的二叉查找树，主要是基于数据库系统，特别是磁盘存储环境下的性能考量：

• 磁盘I/O优化：数据库索引通常很大，无法完全加载到内存中，需要频繁进行磁盘I/O。B+树是一种多路搜索树，其非叶子节点只存储键值和指向子节点的指针，不存储数据记录本身。这使得每个节点可以容纳更多的键值，从而降低了树的高度。查找一个键值时，需要访问的磁盘块数量（树的高度）远少于高度平衡的二叉树（如红黑树），显著减少了磁盘I/O次数，提高了查询效率。
• 范围查询效率高：B+树的所有数据记录都存储在叶子节点上，并且所有叶子节点通过指针相互连接形成一个有序链表。这种结构使得进行范围查询（如 WHERE id BETWEEN 100 AND 200）非常高效，只需定位到范围的起始点，然后沿着叶子节点的链表顺序遍历即可。红黑树虽然也能进行范围查询，但需要进行中序遍历，可能涉及更多的节点访问和回溯，效率相对较低。

红黑树在内存数据库中的适用性

对于纯内存数据库（In-Memory Database, IMDB），数据完全存储在内存中，磁盘I/O不再是性能瓶颈。在这种场景下，红黑树（或其他自平衡二叉搜索树）是完全可行且可能更优的选择：

• 内存操作效率：红黑树是一种高效的自平衡二叉搜索树，其插入、删除、查找操作的平均和最坏时间复杂度均为O(log n)，在内存中表现优异。
• 实现相对简单：相比于B+树，红黑树的结构和平衡调整算法通常更简单一些。
• 节点空间利用率：在内存中，节点大小不再受磁盘块大小的严格限制，红黑树每个节点存储一个键值对，空间利用相对直观。

因此，当数据量适合完全载入内存，并且主要瓶颈在于CPU计算而非I/O时，红黑树因其良好的内存操作性能和相对简单的实现，成为内存数据库索引结构的一个有力候选。许多内存数据库或缓存系统（如Redis的部分数据结构）确实会使用类似红黑树的结构。

86.Java 反射机制：原理、Class对象获取与存储位置

反射的核心原理

Java 反射机制允许程序在运行时动态地获取类的信息并操作类的对象。其核心在于java.lang.Class类的对象，这个对象封装了一个类在运行时的完整元数据（如类名、方法、字段、构造器、注解等）。反射的运用通常始于获取目标类的Class对象。

获取Class对象主要有三种途径：

一是通过类字面常量，例如 Class<?> c = MyClass.class;

二是通过对象的getClass()方法，如 MyClass obj = new MyClass(); Class<?> c = obj.getClass();；

三是使用Class.forName()静态方法，根据类的全限定名动态加载类，如 Class<?> c = Class.forName("com.example.MyClass");。一旦获得了Class对象，便可以利用它提供的API（如newInstance(), getFields(), getMethods(), getDeclaredConstructors()等）来实例化对象、访问或修改字段（即使是私有的）、调用方法等。

Class对象的存储位置

JVM在加载每个类时，会在内存的方法区（Method Area）中为该类创建一个唯一的Class对象实例。在JDK 8及之后版本，方法区的实现变更为元空间（Metaspace），它使用的是本地内存（Native Memory）而非JVM堆内存。无论具体实现如何，Class对象都存储在用于存放类元数据的特定内存区域，作为该类所有运行时信息的入口点。

反射的优缺点

反射极大地增强了Java的灵活性和动态性，是许多框架（如Spring、MyBatis）实现依赖注入、AOP、动态代理等功能的基础。然而，它也伴随着一些缺点：首先，性能开销较大，反射调用涉及查找和解析过程，通常比直接代码调用慢。其次，破坏封装性，反射可以绕过访问修饰符（如private）的限制，可能引发安全风险和维护问题。最后，降低代码可读性，过度使用反射会使代码逻辑变得复杂，不易理解和调试。

87.详解Java类加载器、双亲委派模型及自定义java.lang.String的可行性

Java 类加载器

Java虚拟机（JVM）依赖类加载器（ClassLoader）来动态加载类文件（.class）。主要的类加载器有：

1. 启动类加载器（Bootstrap ClassLoader）：由C++实现，是JVM自身的一部分。负责加载Java核心库（如JAVA_HOME/jre/lib/rt.jar中的java.lang.*等）。开发者无法直接获取其引用。
2. 扩展类加载器（Extension ClassLoader）：由Java实现（sun.misc.Launcher$ExtClassLoader），继承自ClassLoader。负责加载JAVA_HOME/jre/lib/ext目录或java.ext.dirs系统属性指定的路径下的扩展库。
3. 应用程序类加载器（Application ClassLoader）：也称系统类加载器，由Java实现（sun.misc.Launcher$AppClassLoader）。负责加载用户类路径（Classpath）上的类。它是程序中默认的类加载器，可通过ClassLoader.getSystemClassLoader()获取。

此外，开发者可以通过继承java.lang.ClassLoader创建自定义类加载器，以实现从特定来源（如网络、加密文件）加载类，或实现类的热部署等特殊需求。

双亲委派模型

这是Java类加载器普遍遵循的一种工作模式。其核心思想是：当一个类加载器收到加载类的请求时，它首先不会自己尝试加载，而是将请求委托给父加载器去完成。每一层级的加载器都会如此行事，直至顶层的启动类加载器。只有当父加载器反馈无法完成加载请求（在其搜索范围内找不到所需的类）时，子加载器才会尝试自己去加载。

这种模型的主要目的是保证Java核心库的类型安全，防止核心API（如java.lang.Object, java.lang.String）被用户自定义的同名类所覆盖，确保Java平台的稳定运行。

破坏双亲委派模型

在某些特定场景下，需要打破双亲委派模型，常见方式包括：

• 重写loadClass方法：自定义类加载器可以通过重写loadClass方法，改变默认的委派逻辑，例如先尝试自己加载，或者按特定规则委派。这是最直接的破坏方式。
• 线程上下文类加载器（Thread Context ClassLoader）：Java提供了Thread.currentThread().setContextClassLoader()方法，允许为线程设置特定的类加载器。JNDI、JDBC、JCE等SPI（Service Provider Interface）机制广泛使用它，使得顶层API可以调用由应用程序类加载器加载的服务提供者实现类，实际上是父加载器请求子加载器去加载类，逆向了委派流程。
• 模块化系统（如OSGi）：OSGi为每个模块（Bundle）定义了独立的类加载器，它们之间的类加载关系更为复杂，形成了网状结构而非简单的树状委派，以实现模块间的隔离和依赖管理。

能否自定义java.lang.String类？

理论上可以编写一个名为java.lang.String的类，但在标准的Java运行环境中，几乎不可能让JVM加载并使用你自定义的版本来替代核心库中的java.lang.String。原因在于：

• 双亲委派模型：根据委派机制，加载java.lang.String的请求最终会到达启动类加载器，它会加载JRE核心库中的版本。用户自定义的类加载器根本没有机会加载同名类。
• 安全限制：JVM的安全机制禁止加载以java.开头的包中的用户自定义类，这是为了保护核心API不被篡改。

尝试这样做通常会导致类加载错误或安全异常。即便通过特殊手段（如修改启动类加载器路径或使用agent技术）强行替换，也会因破坏了Java平台的基础假设而导致严重的不稳定性和兼容性问题。

在Java中，理论上你可以编写一个自己的类并尝试将其命名为java.lang.String，但是在实践中，这样做会遇到一些显著的限制和问题，主要由Java的类加载机制和安全模型决定：

1. 类加载器的双亲委派模型：正如前面所述，Java的类加载器使用双亲委派模型。当你尝试加载一个类时，类加载器会首先尝试从最顶层的启动类加载器开始，依次向下查找类。由于java.lang.String属于Java核心类库，它会被启动类加载器加载，这发生在任何用户定义的类加载器之前。因此，尽管你可以定义一个名为java.lang.String的类，它永远不会被加载用于替代标准的java.lang.String类，除非你完全绕过了标准的类加载机制。
2. 安全限制：Java的安全管理器也会阻止