Java 面试题›Java 基础面试题›为什么 Java 不支持多继承?
面试考察点
语言设计哲学理解:面试官不仅仅是想知道 “Java 不支持多继承” 这个事实,更是想知道你是否理解背后的设计哲学——Java 追求简单、安全、易用,宁可牺牲一些灵活性也要避免复杂的陷阱。
问题分析能力:考察你是否了解多继承带来的经典问题(菱形继承/钻石问题),能否清晰解释为什么这些问题在多继承场景下难以解决。
替代方案掌握:看你是否知道 Java 通过 “单继承 + 多接口实现” 的方式弥补了多继承的缺失,以及接口默认方法(JDK 8)如何进一步增强这种能力。
核心答案Java 不支持类的多继承,核心原因是 避免菱形继承问题带来的歧义和复杂性。 一句话概括:多继承会导致方法调用的二义性,Java 为了保持语言简单,选择了 “单继承 + 多接口实现” 的设计。 **** ****
设计选择
说明
类继承
只支持单继承,一个类只能有一个直接父类
接口实现
支持多实现,一个类可实现多个接口
设计哲学
简单优于灵活,避免 “菱形继承” 等复杂问题
...
Java 面试题›Java 基础面试题›如何理解 Java 中的多态?
面试考察点
面向对象理解深度:面试官不仅仅是想知道你能不能说出多态的定义,更是想知道你是否理解多态作为面向对象 “封装、继承、多态” 三大特性之一的核心价值,以及它如何实现 “同一接口,不同实现” 的设计思想。
底层原理掌握:考察你是否了解多态在 JVM 层面的实现机制,包括虚方法表(vtable)、动态分派、方法调用指令(invokevirtual、invokeinterface)等,这是区分 “会用” 和 “精通” 的关键。
实践应用能力:看你能否举出实际开发中多态的应用场景,如策略模式、工厂模式、Spring 的依赖注入等,以及是否了解多态的边界(如字段没有多态性、静态方法没有多态性)。
核心答案多态是 Java 面向对象的核心特性之一,指 同一操作作用于不同对象时,产生不同的行为结果。 一句话概括:父类引用指向子类对象,运行时根据实际对象类型调用对应的方法。 多态的实现需要满足 三个必要条件:
条件
说明
代码示例
继承/实现
必须有父子类或接口实现关系
class Dog ext ...
Java 面试题›Java 基础面试题›什么是泛型?为什么要使用它?
面试考察点
基础概念掌握:面试官不仅仅是想知道泛型是什么,更是想知道你是否理解泛型的本质——参数化类型,以及它在编译期和运行期的不同表现。
类型安全意识:考察你是否清楚泛型如何解决类型安全问题,能否对比 “泛型前” 和 “泛型后” 的代码差异,理解为什么 ClassCastException 从运行期提前到了编译期。
底层原理深度:考察你是否了解 类型擦除 机制,能否解释为什么 List<String> 和 List<Integer> 在运行时是同一个类,以及泛型与 Java 向后兼容的设计权衡。
核心答案Java 泛型(Generics) 是 JDK 5 引入的特性,允许在定义类、接口和方法时使用 类型参数,将类型从 “具体” 变成 “参数化”,从而在编译期进行类型检查。 **** **** **** ****
泛型核心价值
说明
类型安全
编译期检查类型,将运行时异常提前到编译期
消除强转
无需手动类型转换,代码更简洁
代码复用
...
Java 面试题›Java 基础面试题›什么是反射机制?为什么反射慢?
面试考察点
基础概念掌握:面试官不仅仅是想知道反射是什么,更是想知道你是否理解 Java 运行时类型信息(RTTI)的本质,以及在运行时获取类信息的能力。
底层原理深度:考察你是否了解反射在 JVM 层面的实现机制,包括类加载、方法区、Class 对象等核心概念,能否解释 “为什么慢” 背后的技术原因。
工程实践意识:考察你是否清楚反射的应用场景(框架开发、动态代理、注解处理)以及性能优化策略,避免在生产环境滥用。
核心答案Java 反射机制是指在程序运行状态中,对于任意一个类,都能够知道这个类的所有属性和方法;对于任意一个对象,都能够调用它的任意方法和属性。这种动态获取信息以及动态调用对象方法的功能称为 Java 语言的反射机制。
特性
说明
运行时类型检查
程序运行时获取对象所属的类信息
动态加载类
运行时加载编译期间未知的类
动态调用方法
运行时调用任意对象的方法
访问私有成员
突破封装限制,访问 private 成员
为什么反射慢? 主要有以下几个原因:
性能瓶颈
具体 ...
Java 面试题›Java 基础面试题›while (true) 和 for (;;) 哪个性能更好?
面试考察点
编译原理理解:面试官想知道你是否了解 Java 编译器如何处理不同语法形式的代码,以及它们在字节码层面是否存在差异。
性能优化意识:考察你是否具备从底层角度分析代码性能的思维,而不是停留在语法层面做无谓的纠结。
工程实践认知:验证你是否能区分 “理论差异” 和 “实际影响”,是否了解现代编译器的优化能力。
核心答案性能完全相同,没有任何区别。
对比项
while(true)
for(;;)
字节码
完全一致
完全一致
执行效率
相同
相同
JVM 优化
相同
相同
可读性
✅ 更直观
需要适应
结论:两者经过 javac 编译后生成的字节码完全相同,运行时性能零差异。选择哪个完全取决于团队编码风格和个人习惯。
深度解析一、字节码验证:编译后完全一致我们用实际代码来验证:
public class InfiniteLoopTest { // while(true) 版本 public void whileLoop() & ...
Java 面试题›Java 基础面试题›接口和抽象类的区别是什么?怎么选择?
面试考察点
基础概念掌握:面试官不仅仅是想知道你会不会定义接口和抽象类,更是想知道你是否理解它们在设计层面的本质区别—— “契约” 与 “模板” 的不同定位。
设计能力考察:通过这个问题,面试官想评估你的面向对象设计思维,能否根据实际场景做出合理的抽象选择,而不是滥用继承或接口。
版本演进意识:JDK 8 之后接口引入了默认方法和静态方法,这让接口和抽象类的界限变得模糊,考察你是否跟上 Java 的演进,以及在新特性下的选择逻辑。
核心答案一句话总结:接口定义 “能做什么”(行为契约),抽象类定义 “是什么”(本质模板)。
核心区别对比
对比维度
接口
抽象类
设计理念
行为契约,定义 “能做什么”
模板模式,定义 “是什么”
继承关系
implements,可多实现
extends,单继承
成员变量
只能是 public static final 常量
任意访问修饰符,可定义普通成员变量
方法实现
JDK 8 前:只能抽象方法JDK 8+:可有 default、static 方 ...
Java 面试题›Java 基础面试题›String str = new String("abc") 创建了几个对象?
面试考察点
基础概念掌握:面试官不仅仅是想让你回答一个数字,更是想考察你是否理解 Java 对象创建机制、字符串常量池的工作原理,以及字面量与 new 关键字的区别。
分情况分析能力:这道题的答案取决于字符串常量池的当前状态,考察你是否有 “条件思维”,能否识别出不同的执行场景。
JVM 内存模型理解:考察你是否清楚堆内存、字符串常量池的位置关系(JDK 6 vs JDK 7+ 的差异),以及对象在内存中的存储方式。
核心答案这道题的答案 取决于字符串常量池中是否已存在 "abc": **** **** **** ****
场景
常量池状态
创建对象数
对象位置
首次执行
不存在 “abc”
2 个
常量池 1 个 + 堆 1 个
非首次执行
已存在 “abc”
1 个
仅堆中 1 个
一句话总结:new String("abc") 至少创建 1 个堆对 ...
Java 面试题›Java 基础面试题›String、StringBuilder 和 StringBuffer 的区别?
面试考察点
基础掌握度:面试官不仅仅是想知道这三者的区别,更是想确认你是否理解 Java 字符串的不可变性设计,以及为什么需要 StringBuilder 和 StringBuffer。
线程安全意识:考察你是否清楚 StringBuilder 和 StringBuffer 在线程安全上的差异,能否根据业务场景选择合适的类。
性能优化意识:是否了解字符串拼接在不同场景下的性能差异,能否写出高性能的字符串处理代码。
核心答案
对比项
String
StringBuilder
StringBuffer
可变性
不可变
可变
可变
线程安全
安全(不可变)
不安全
安全(synchronized)
性能
拼接差
最快
较快
适用场景
少量字符串、常量
单线程拼接
多线程拼接
出现版本
JDK 1.0
JDK 1.5
JDK 1.0
一句话总结:单线程用 StringBuilder,多线程用 StringBuffer,常量用 String ...
Java 面试题›Java 基础面试题›String 为什么设计成 final 不可变的?
面试考察点
基础原理理解:面试官不仅仅是想知道 String 是不可变的,更是想考察你是否理解 Java 设计者的深层考量,以及不可变对象的设计思想。
多线程安全意识:考察你是否意识到不可变性是实现线程安全最简单、最可靠的方式之一。
性能优化思维:考察你是否了解字符串常量池、哈希缓存等 JVM 底层优化机制。
安全性认知:考察你对系统安全的敏感度,理解不可变性在类加载、敏感信息保护等方面的重要性。
核心答案String 被设计成 final 不可变类,主要基于 5 大核心原因: **** **** **** **** ****
设计原因
核心价值
实际效果
字符串常量池优化
内存复用
相同字符串只存一份,节省堆内存
线程安全
无锁并发
不可变对象天生线程安全,无需同步
哈希值缓存
性能提升
hashCode() 只需计算一次,后续直接复用
安全性保障
系统稳定
防止类加载、文件路径等被篡改
设计一致性
行为可预测 ...
假设你的博客友情链接越来越长,某天突然想知道:谁还在线,谁已经变成了数字废墟,谁只是慢得像在火星上托管?
逐个打开当然可以,但程序员更适合造一台“网站存活雷达”。这篇文章会使用 JDK 21 正式提供的 Virtual Threads(虚拟线程),同时探测多个网址,记录 HTTP 状态、耗时和失败原因,最后列出最慢的几个站点。
整个示例只有一个 .java 文件,不依赖 Spring、第三方 HTTP 客户端或构建工具。它会用到:
java.net.http.HttpClient 发送同步 HTTP 请求;
Executors.newVirtualThreadPerTaskExecutor() 为每个探测任务创建一个虚拟线程;
Semaphore 限制真正同时访问外部网站的数量;
连接超时与单次请求超时,避免任务永远挂起;
record 保存不可变的探测结果。
本文资料按 2026-09-17 的官方状态核对。Virtual Threads 已通过 JEP 444 在 JDK 21 正式交付,不再是 Preview Feature(预览特性);JDK 24 又通过 JEP 491 ...
