Java八股文——Java基础「概念篇」

参考小林Coding和Java Guide

说一下Java的特点

• 平台无关性：“Write Once, Run Anywhere”其最大的特点之一。Java编译器将源代码编译成字节码，该字节码可以在任何安装了JVM的系统上运行。
• 面向对象：Java是一门严格的面向对象编程语言，几乎一切都是对象。面向对象编程（OOP）特性使得代码更易于维护和重用，包括类（class）、对象（object）、封装（encapsulation）、继承（inheritance）、多态（polymorphism）和抽象（abstraction）。
• 内存管理：Java拥有自己的垃圾回收机制，自动管理内存并回收不再使用的对象。开发者无需手动管理内存，从而减少了内存泄漏和其他与内存相关的问题。

JavaSE vs JavaEE

首先，Java SE (Java Platform, Standard Edition) 是整个Java平台的核心和基础。

• 它包含了Java编程语言最根本的组件，比如Java虚拟机（JVM）、核心类库（像java.lang, java.util, java.io这些包里的类，提供了集合框架、IO操作、多线程、网络编程等基础功能）。
• 我们可以把Java SE看作是开发任何Java应用程序的起点。无论是桌面应用程序、命令行工具，甚至是简单的服务器端应用，以及后面要提到的Java EE应用，它们都必须依赖于Java SE提供的运行环境和核心API。

然后，Java EE (Java Platform, Enterprise Edition) 是建立在Java SE之上的一个更为庞大的平台。

• 它专门为开发和部署大规模、分布式、高可用、安全的企业级应用程序而设计。
• Java EE本身并不直接提供实现，而是定义了一系列标准和规范（Specifications）。这些规范涵盖了企业应用中常见的各种需求，比如：
  • Web层技术：Servlet、JSP、JSF
  • 业务逻辑层：EJB (Enterprise JavaBeans)
  • 数据持久化：JPA (Java Persistence API)
  • 事务管理：JTA (Java Transaction API)
  • 消息服务：JMS (Java Message Service)
  • 还有像Contexts and Dependency Injection (CDI)、Bean Validation等等。
• 这些规范由应用服务器（Application Server）厂商（如Tomcat、JBoss/WildFly、WebSphere、WebLogic等）来实现。开发者依据这些EE规范来编写代码，然后将应用部署到这些应用服务器上运行。
• 所以，Java EE的目标是简化企业级应用的开发，通过提供一套标准化的组件模型和API，来处理诸如并发、事务、安全、分布式计算等复杂问题。

简单总结一下它们的关系和定位：

• Java SE是基础：它提供了Java语言的核心功能和运行环境。没有Java SE，就没有Java EE。
• Java EE是扩展：它在Java SE的基础上，增加了一整套面向企业级应用的规范和API，用于构建复杂的、可伸缩的、安全的服务端应用程序，特别是Web应用程序和大型后台系统。

所以，Java SE更适合开发桌面应用或一些基础的、简单的服务器程序。而当我们需要构建功能复杂、需要处理高并发、事务管理、分布式部署等需求的企业级应用或Web应用时，Java EE（或者现在更多时候，我们会选择像Spring这样的现代企业级框架，它们也大量借鉴或实现了Java EE中的规范）就会是更合适的选择。

什么是字节码?采用字节码的好处是什么?

面试官您好，关于字节码以及它带来的好处，我的理解是这样的：

首先，什么是字节码？
字节码，在Java的语境下，它是一种中间代码。当我们编写的Java源代码（也就是.java文件）经过Java编译器（javac）编译之后，生成的并不是可以直接在特定操作系统或CPU上运行的机器指令，而是这种字节码文件。这些字节码文件通常以.class作为扩展名。
您可以把字节码看作是Java虚拟机（JVM）能够直接理解和执行的指令集。它不依赖于任何特定的硬件平台或操作系统，是为JVM这种抽象计算机设计的。

然后，采用字节码的好处是什么？ 我认为主要有以下几点：

• 实现跨平台性（“一次编译，到处运行” - Write Once, Run Anywhere）：
  这是字节码最核心、最显著的好处。因为字节码是平台无关的，所以开发者只需要将Java源代码编译一次生成.class字节码文件。之后，这份字节码文件就可以在任何安装了相应版本JVM的操作系统（如Windows, Linux, macOS等）上运行。JVM会充当一个“翻译官”的角色，将这些通用的字节码解释执行，或者通过JIT（Just-In-Time）编译器将其编译成特定平台的本地机器码来执行。这极大地简化了跨平台应用的开发和部署工作。
• 提高安全性：
  JVM在加载和执行字节码之前，会进行一个非常重要的步骤叫做字节码校验（Bytecode Verification）。这个校验过程会仔细检查字节码的格式是否正确、操作是否合法（比如类型是否匹配、会不会导致栈溢出、是否有非法的内存访问等），从而有效地防止了恶意代码或者有缺陷的代码对底层系统造成破坏。这比直接执行从外部获取的本地机器码要安全得多。
• 为性能优化提供了坚实基础：
  虽然字节码最初可以被解释执行，这保证了较快的启动速度，但现代的JVM（比如我们常用的HotSpot JVM）都内置了JIT（Just-In-Time）即时编译器。JIT编译器能够在程序运行时，动态地监测哪些代码是“热点代码”（即执行频率非常高的代码段），然后将这些热点字节码编译成本地机器码，并且还会进行各种深入的优化（如方法内联、逃逸分析等）。这样一来，Java程序在长时间运行后，其性能可以得到显著提升，甚至在某些情况下能够接近或超过编译型语言的水平。字节码作为一种稳定的、结构化的中间表示，为这些高级的运行时优化技术提供了可能性。
• 支持语言无关性和动态性：
  • JVM和字节码规范并不仅仅为Java语言服务。任何其他编程语言，只要其编译器能够将源代码编译成符合JVM规范的字节码，那么该语言编写的程序就可以在JVM上运行。这就形成了一个庞大的JVM生态系统，包括了像Scala、Kotlin、Groovy等多种语言，它们都可以共享JVM的跨平台性、自动内存管理（垃圾回收）、多线程等优秀特性。
  • 字节码也使得Java程序可以在运行时动态加载类，这为实现像反射、动态代理、AOP（面向切面编程）等高级特性提供了支持。

总的来说，字节码是Java平台实现其核心特性（如平台无关性、安全性、以及通过JIT实现的高性能潜力）的关键技术。它作为源代码和特定平台机器码之间的重要桥梁，为Java生态带来了诸多好处。

Java的优势和劣势是什么

首先，谈谈Java的优势：

• 卓越的跨平台性：这是Java最为人称道的特性之一。通过Java虚拟机（JVM），Java真正实现了“一次编译，到处运行”，这使得应用程序可以非常方便地部署在不同的操作系统和硬件平台上，极大地增强了其可移植性。
• 纯粹的面向对象设计：Java从设计之初就是一门面向对象的语言，它完整支持封装、继承和多态等核心特性。这种设计哲学有助于构建模块化、高内聚、低耦合的系统，使得代码更易于维护、扩展和复用，尤其适合开发大型复杂应用。
• 强大且成熟的生态系统：Java拥有一个非常庞大且活跃的生态圈。这包括了像Spring全家桶、MyBatis、Netty等功能强大的开源框架，海量的第三方库和工具，以及一个庞大的全球开发者社区。这为企业级应用开发提供了坚实的基础和丰富的解决方案，能够显著提高开发效率和项目质量。
• 自动内存管理（GC）：Java通过垃圾回收机制自动管理内存的分配和释放。这意味着开发者不需要像C/C++那样手动处理内存，从而大大降低了内存泄漏和野指针等问题的风险，让开发者能更专注于业务逻辑实现，同时也提升了程序的健壮性。
• 内建的并发支持：Java在语言层面和核心库中都提供了对多线程编程的良好支持。例如，它有Thread类、synchronized关键字以及功能强大的java.util.concurrent（JUC）并发包，这些都使得开发高并发、高性能的应用相对更为便捷和可控。
• 高度的安全性和稳定性：Java设计了一套相对完善的安全模型，包括类加载机制、字节码校验、安全管理器（沙箱机制）等，这使其在构建安全的网络应用和企业级系统时具有天然优势。同时，经过二十多年的发展和大规模商业应用的检验，Java的稳定性和可靠性得到了广泛认可，其版本迭代也比较注重向后兼容性。

当然，Java也存在一些相对的劣势：

• 运行时性能开销与启动速度：相较于C或C++这类直接编译成原生机器码的语言，Java程序因为运行在JVM之上，在执行效率上会存在一定的开销。虽然JVM通过JIT（即时编译）等技术进行了大量优化，但在纯计算密集型任务或对延迟极度敏感的场景下，可能仍有差距。特别是在应用启动阶段，JVM的初始化以及类加载过程可能会导致启动时间相对较长，这在某些微服务或Serverless架构下可能需要特别关注。
• 语法相对繁琐：尽管Java语言本身也在不断演进，比如从Java 8开始引入了Lambda表达式、Stream API以及后续版本中的类型推断等特性来简化代码，但与一些更现代的语言（如Kotlin、Scala）或动态类型语言（如Python）相比，Java在某些情况下仍然需要编写更多的样板代码，语法表达上可能显得不够简洁。
• 内存占用：JVM本身以及Java对象（例如对象头）都会带来一定的内存开销。因此，在内存资源非常受限的环境下，比如一些嵌入式设备或者小型容器实例，Java应用可能会面临较大的内存压力。
• 面向对象的“重量感”：虽然面向对象是Java的核心优势，但在处理一些非常简单的小型任务或脚本类工作时，其严格的面向对象范式有时可能会让程序结构显得有些“重”，不如某些脚本语言那样灵活和轻量。不过，Java也在通过引入函数式编程特性等方式来提升这方面的灵活性。

总的来说，我认为Java凭借其无与伦比的生态系统、成熟的稳定性、跨平台能力以及在并发处理方面的优势，在企业级应用开发、大型分布式系统、大数据处理和安卓应用开发等领域依然是中流砥柱。虽然它在性能、内存消耗和语法简洁性方面存在一些权衡，但JVM的持续优化和语言特性的不断增强也在努力弥补这些不足。选择是否使用Java，更多的是需要根据具体的项目需求、团队熟悉度和场景特点来综合考量。

Java为什么是跨平台的

关于Java为什么能够支持跨平台，我的理解是这主要归功于Java虚拟机，也就是我们常说的JVM。

具体来说，我们编写的Java源代码（.java文件）首先会经过Java编译器编译，但它编译后生成的不是特定平台的机器码，而是一种与平台无关的中间代码，叫做字节码（.class文件）。这个字节码文件本身是不能直接在任何操作系统上运行的。

这时候，JVM就发挥了关键作用。针对不同的操作系统和硬件平台，比如Windows、Linux、macOS等，都有对应版本的JVM实现。当我们运行一个Java程序时，该平台上的JVM会负责加载这些字节码文件。然后，JVM会将这些平台无关的字节码解释执行，或者通过JIT（Just-In-Time）即时编译器将其编译成本地操作系统能够识别和执行的机器指令。

所以，可以把JVM理解为一个“适配层”或者“翻译官”。它在我们的Java程序和底层操作系统之间搭建了一座桥梁。正是因为有了JVM，我们开发者编写的Java代码只需要编译一次生成字节码，这份字节码就可以在任何安装了相应JVM的平台上运行，从而真正实现了“一次编译，到处运行”（Write Once, Run Anywhere）的目标。

这里也需要明确一点，虽然我们的Java应用程序是跨平台的，但JVM本身并不是。JVM通常是用C或C++等语言针对特定操作系统和硬件架构开发的，是编译后的本地代码。因此，不同的平台需要安装不同版本的JVM，正是这些平台特定的JVM，保证了同一份Java字节码能够在各种不同的环境下正确执行。

JVM、JDK、JRE三者关系

关于JVM、JDK和JRE这三者的关系，我的理解是它们是Java平台的核心组成部分，并且形成了一个清晰的层级包含关系。

• 首先，最底层或者说最核心的是JVM，即Java虚拟机。它是Java程序得以运行的基础环境。JVM的主要职责是加载和执行由Java编译器生成的字节码文件，它负责内存管理、垃圾回收等，也是Java实现跨平台特性的关键所在。
• 其次是JRE，也就是Java运行时环境。JRE可以理解为是在JVM的基础上，增加了Java程序运行所必需的核心类库。所以，如果一个用户只需要运行已经开发好的Java应用程序，那么在他的机器上安装JRE就足够了，JRE为程序提供了完整的运行支持。
• 最后是JDK（Java Development Kit），即Java开发工具包。JDK是面向我们Java开发者的，它包含了JRE的全部内容——也就是说，JDK里面既有JVM，也有核心类库。除此之外，JDK还提供了我们开发Java程序所需要的各种工具，比如编译器（javac）、调试器（jdb）、性能分析工具、打包工具（jar）等等。

所以，简单来说，它们的关系就是：JDK包含了JRE，而JRE又包含了JVM。我们开发者通常需要安装JDK来进行开发工作，而普通用户运行Java程序只需要JRE就够了。

为什么Java解释和编译并存？

面试官您好，关于Java为什么同时具备解释和编译的特性，我的理解是这样的：

首先，我们编写的Java源代码（.java文件）会经过javac编译器进行一次编译，生成的是平台无关的字节码文件（.class文件）。这一步是明确的编译过程。

然后，当这些字节码文件在JVM中运行时，JVM内部实际上采用了解释执行和即时编译（JIT, Just-In-Time Compilation） 相结合的策略。这主要是为了在程序的启动速度和长期运行性能之间取得一个平衡。

具体来说：

• 解释执行：在程序刚开始运行或者某些代码片段执行次数较少时，JVM中的解释器会逐条将字节码指令翻译成对应平台的本地机器码并立即执行。这样做的好处是程序启动相对较快，无需等待额外的编译时间。
• 即时编译（JIT）：对于那些被频繁执行的“热点代码”，JVM会通过内部的一些机制（比如调用计数器或者循环回边计数器）来识别它们。当一段代码被识别为热点代码后，JIT编译器就会在运行时介入，将这部分字节码编译成本地机器码，并且可能会进行一些深度优化。编译生成的机器码会被缓存起来，后续再执行到这段代码时，就可以直接运行优化后的机器码，从而大大提高执行效率。

所以，Java的这种设计使得它：

• 通过解释器保证了较快的启动速度和对不常用代码的快速响应。
• 通过JIT编译器对热点代码进行编译和优化，确保了程序在长时间运行过程中的高性能。

因此，我们可以说Java语言在源代码到字节码阶段是编译型的，而在JVM执行字节码的阶段，它默认采用了这种解释器与JIT编译器混合的模式。这种混合模式，尤其是在像HotSpot这样的现代JVM中，是其能够兼顾灵活性和高性能的关键原因之一。

Jvm是什么

面试官您好，JVM，全称是Java虚拟机（Java Virtual Machine）。

在我理解中，JVM最核心的作用是作为Java程序的运行环境。我们编写的Java源代码经过编译器编译后会生成一种叫做“字节码”的中间文件（.class文件）。JVM的主要工作就是负责加载这些字节码，然后通过其内部的执行引擎，将这些与平台无关的字节码指令解释并映射到当前操作系统和CPU能够识别和执行的本地机器指令，从而让Java程序跑起来。

其次，JVM是Java语言实现“一次编译，到处运行”这个跨平台特性的基石。它在我们的Java应用程序和底层的操作系统硬件之间构建了一个抽象层，有效地屏蔽了不同操作系统平台之间的差异。因此，同一份Java字节码文件，不需要做任何修改，就可以在任何安装了对应版本JVM的机器上运行，无论是Windows、Linux还是macOS。

更进一步来说，JVM本身也可以被看作是一个抽象的、虚拟的计算机。它拥有自己的一套指令集规范（即字节码指令），有自己管理的内存区域（比如我们常说的堆、栈、方法区等），并且还负责诸如内存分配、垃圾自动回收等重要的底层任务。这为Java程序提供了一个稳定、安全且高效的运行环境。

所以，简单总结一下，JVM不仅是Java程序能够运行起来的引擎，更是保证其可移植性和平台无关性的关键所在。

编译型语言和解释型语言的区别？

面试官您好，关于编译型语言和解释型语言，我理解它们的主要区别体现在代码的转换时机、执行效率以及跨平台能力这几个方面。

首先，编译型语言在程序执行之前，会经历一个完整的编译过程。这个过程会把我们写的源代码一次性地转换成目标机器可以直接执行的机器码，并通常会生成一个独立的可执行文件。

• 这种方式的优点在于，由于代码在运行前已经编译和优化完毕，所以执行速度通常会比较快。
• 不过，它的一个挑战在于跨平台性。因为编译生成的是针对特定平台的机器码，如果想在不同的操作系统或CPU架构上运行，一般需要重新编译源代码。C语言和C++就是这类语言的典型代表。

然后是解释型语言。它不需要在运行前进行完整的、一次性的编译。相反，它的源代码是在程序运行时，由一个叫做“解释器”的程序逐行或逐段地读取、分析，并即时转换为机器指令来执行的。它通常不会生成独立的可执行文件。

• 这种方式的主要优势是跨平台性非常好。只要目标平台上有相应的解释器，同一份源代码就可以直接运行，非常灵活。
• 然而，由于是边解释边执行，它的执行效率通常会比编译型语言稍慢一些。我们平时用到的Python、JavaScript就是典型的解释型语言。

所以，简单总结一下，核心差异在于代码是什么时候被翻译成机器能懂的指令：编译型是运行前一次搞定，解释型则是运行时边翻译边执行。

Python和Java区别是什么？

面试官您好，关于Python和Java的区别，在我看来，它们都是非常强大和流行的编程语言，但在设计理念、执行方式和适用场景上有一些显著的不同。

首先，最核心的一点正如您提到的，是它们的执行机制：

• Java 是一种编译型语言，但它的编译过程比较特殊。Java源代码（.java文件）首先会被Java编译器（javac）编译成一种与平台无关的中间代码，也就是我们常说的字节码（.class文件）。然后，这些字节码文件在Java虚拟机（JVM）上运行。JVM会负责将这些字节码解释执行，或者通过JIT（Just-In-Time）即时编译器将其编译成本地机器码来优化性能。这种机制使得Java拥有了“一次编译，到处运行”的跨平台能力。
• Python 通常被归类为解释型语言。Python代码在执行时，是由Python解释器逐行读取、分析并转换为机器能够理解的指令来执行的。虽然Python为了效率也会将源代码编译成字节码（.pyc文件）作为中间步骤，但其整体的执行模型更侧重于解释执行，这使得Python在开发和调试时非常灵活，修改代码后能立即看到效果。

除了执行机制，还有其他一些重要的区别：

• 类型系统：
  • Java是静态类型语言，并且是强类型。这意味着所有变量的类型在编译时就必须声明并确定，编译器会进行严格的类型检查，这有助于在开发早期发现很多潜在的类型错误。
  • Python是动态类型语言，也是强类型。变量的类型是在运行时根据赋给它的值来确定的，不需要预先声明。这使得Python代码通常更简洁，开发效率有时更高，但某些类型相关的错误可能要到运行时才会暴露。
• 性能：
  • 一般来说，由于Java有JVM的JIT编译优化等机制，以及其静态类型特性，其执行性能通常会优于Python，尤其是在处理计算密集型任务和构建大型、高并发应用时。
  • Python的执行速度相对较慢，但在很多情况下，其快速的开发周期和丰富的库可以弥补这一点。而且，对于性能敏感的部分，Python也可以通过调用C/C++编写的扩展库来提升。
• 应用领域：
  • Java 凭借其稳定性、高性能和庞大的生态系统，广泛应用于大型企业级后端应用开发、安卓移动应用开发、大数据处理（如Hadoop、Spark生态中的许多组件）等领域。
  • Python 以其简洁的语法、丰富的标准库和第三方库，在数据科学、人工智能、机器学习、Web开发（使用Django、Flask等框架）、自动化脚本、网络爬虫等方面非常受欢迎。
• 语法和开发效率：
  • Java 的语法相对更为严谨和规范，代码量通常会比Python多一些，对于初学者来说学习曲线可能稍陡峭一点。
  • Python 的语法设计强调简洁优雅、可读性强，通常被认为更容易上手，能够让开发者用更少的代码完成同样的功能，因此在很多场景下开发效率非常高。

总的来说，Java和Python都是非常优秀的语言，它们各自有其擅长的领域和独特的优势。选择哪种语言更多是取决于项目的具体需求、团队的技术栈、对性能的要求以及开发周期等因素的综合考量。

AOT 有什么优点？为什么不全部使用 AOT 呢？

面试官您好，关于AOT（Ahead-of-Time，JDK9引入）编译，它与我们更常讨论的JIT（Just-In-Time）即时编译是两种不同的编译策略。

AOT（Ahead-of-Time）编译 指的是在程序运行之前，就将字节码或者源代码直接编译成本地机器码。

AOT 的主要优点包括：

• 更快的启动速度：
  这是AOT最显著的优点之一。因为程序在启动时已经是本地机器码了，不需要像JIT那样在运行时花费时间进行解释执行、分析热点代码、然后才进行编译。对于一些对启动时间敏感的应用（比如命令行工具、短生命周期的Serverless函数、或者某些桌面应用），AOT可以带来非常明显的体验提升。
• 更早达到峰值性能（或者说，初始性能更好）：
  JIT编译的程序需要一个“预热”阶段，在这个阶段，JIT编译器会识别并优化热点代码。而AOT编译的程序从一开始就以编译后的本地代码运行，所以它能更快地达到一个较高的性能水平，虽然这个峰值性能可能不如经过充分动态优化的JIT代码。
• 减少运行时内存和CPU开销（对于编译过程本身）：
  由于编译过程在运行前已经完成，运行时就不再需要JIT编译器这个组件了，也就不需要为JIT编译过程分配CPU时间和内存资源。这对于资源受限的环境（如嵌入式设备或内存非常紧张的容器）可能是有利的。
• 部署包可能更小（特定情况下）：
  比如使用GraalVM的Native Image技术进行AOT编译，它可以进行积极的“死代码消除”（Dead Code Elimination），只将程序实际用到的类和方法编译进最终的可执行文件，可能会生成一个比包含完整JRE和所有字节码的传统部署包更小的独立可执行文件。

那么，为什么不全部使用AOT呢？这主要是因为AOT也有其局限性，或者说JIT在某些方面具有不可替代的优势：

• 无法进行基于运行时信息的动态优化：
  • 这是JIT最核心的优势。JIT编译器在程序运行时，可以收集到大量关于代码实际执行情况的信息，比如哪些代码路径被频繁执行、方法调用的实际目标类型、分支预测的成功率等。基于这些动态信息，JIT可以进行非常激进和精确的优化，例如：
    • 方法内联（Inlining）：根据实际调用情况决定是否内联。
    • 去虚拟化（Devirtualization）：如果发现某个接口或虚方法调用在运行时总是指向同一个具体实现，JIT可以将其转换为直接调用，消除虚方法调用的开销。
    • 分支预测优化：根据实际分支走向调整代码布局。
    • 逃逸分析与锁消除/标量替换：判断对象是否逃逸出方法或线程，从而进行栈上分配、锁消除等优化。
  • AOT编译器在编译时缺乏这些运行时信息，因此它所做的优化通常是比较保守的、基于静态分析的。这意味着对于长时间运行的、计算密集型的复杂应用，经过充分预热和优化的JIT编译代码，其峰值性能往往能够超过AOT编译的代码。
• 平台依赖性增强：
  AOT编译的结果是特定平台（CPU架构+操作系统）的本地机器码。如果想在不同的平台上运行，就需要为每个平台单独进行AOT编译和分发，这在一定程度上牺牲了Java字节码“一次编译，到处运行”的便利性。而JIT是在目标平台上即时编译字节码，自然适应当前平台。
• 编译时间较长：
  将所有代码都预先编译成本地代码，特别是进行深度优化时，编译过程可能会非常耗时，这会增加应用的构建时间。
• 对Java动态特性的支持可能受限或更复杂：
  Java有很多动态特性，比如反射、动态类加载、动态代理等。AOT编译（尤其是像GraalVM Native Image这种追求“封闭世界假设”的）在处理这些动态特性时，可能需要开发者进行额外的配置来告知编译器哪些类和方法在运行时可能被动态访问，否则这些代码可能被错误地认为是“死代码”而被消除。这增加了使用的复杂性。
• 程序包体积可能更大（如果不能有效进行死代码消除）：
  如果AOT编译器不能很好地进行死代码消除，而将所有可能的代码路径都编译成本地代码，最终生成的可执行文件可能会比只包含字节码的JAR包大很多。

总结来说：
AOT和JIT各有其优势和适用场景。AOT更适合对启动速度要求极高、运行时间较短或者资源非常受限的场景。而JIT则凭借其强大的动态优化能力，在长时间运行的、追求极致吞吐量和峰值性能的企业级应用中仍然占据主导地位。

现代JVM如HotSpot本身也采用了分层编译的策略，结合了解释执行、C1（Client）JIT编译器（快速编译，优化较少，提升启动性能）和C2（Server）JIT编译器（慢速编译，深度优化，提升峰值性能），在某种程度上也是在平衡启动速度和峰值性能。像GraalVM这样的技术，则在AOT领域做了很多探索和突破，使得Java在某些特定场景下也能享受到AOT的好处。所以，并不是一个完全取代另一个的问题，而是根据应用需求选择合适的技术策略。

Oracle JDK 和 OpenJDK的区别，以及如何选择

面试官您好，Oracle JDK 和 OpenJDK 是Java开发和运行环境的两种主要提供形式，它们之间既有紧密的联系，也有一些关键的区别，尤其是在许可、支持和一些附加功能（尽管这点差异已逐渐缩小）方面。

核心关系：

• OpenJDK是“根”：OpenJDK 是 Java SE 平台的开源参考实现，遵循GPL v2许可证（带有Classpath Exception，允许链接到非GPL代码）。它包含了Java虚拟机（HotSpot JVM）、Java类库和Java编译器等核心组件。可以说，OpenJDK是所有JDK变体的基础和核心。
• Oracle JDK是基于OpenJDK构建的：Oracle JDK 是 Oracle 公司提供的官方商业版JDK。它基于 OpenJDK 的源代码构建，并在此基础上可能会添加一些商业特性、经过更广泛的测试，并提供商业支持。

主要区别：

• 许可证 (Licensing) - 这是最重要的区别，且历史上有较大变化：
  • OpenJDK：通常是完全免费和开源的，遵循 GPLv2 with Classpath Exception。这意味着你可以自由地使用、修改和分发它，包括用于商业用途。
  • Oracle JDK：
    • JDK 8 及更早版本 (直到8u202)：采用的是 “BCL” (Binary Code License)，允许免费用于通用计算，但在某些商业场景（如嵌入式系统或大规模分发）下有限制。
    • JDK 11 到 JDK 16：Oracle 改变了许可策略，采用 “OTNLA” (Oracle Technology Network License Agreement)。这意味着，Oracle JDK 11-16 版本对于个人开发、测试和学习是免费的，但用于生产环境则需要商业付费订阅。这个变化引起了社区的广泛关注和讨论。
    • JDK 17 及更高版本 (LTS版本)：Oracle 再次调整了许可，推出了新的 “No-Fee Terms and Conditions” (NFTC) 许可。根据这个许可，Oracle JDK 17 及后续的LTS版本（如JDK 21）对于所有用户（包括商业用户）在生产环境中都是免费的，并且Oracle会为这些LTS版本提供数年的免费公开更新。这是一个非常重要的变化，使得Oracle JDK重新成为一个对许多企业具有吸引力的免费选择。
• 特性差异 (逐渐缩小)：
  • 历史上：Oracle JDK 曾经包含一些 OpenJDK 中没有的商业特性，例如 Java Flight Recorder (JFR)、Java Mission Control (JMC)、Application Class-Data Sharing (AppCDS) 的某些高级功能、以及一些专有的字体渲染引擎或加密模块。
  • 现状：随着时间的推移，Oracle 已经将许多曾经的商业特性（如JFR, JMC, ZGC, Shenandoah GC等）贡献给了 OpenJDK 项目。因此，从 JDK 11 开始，Oracle JDK 和 OpenJDK 在功能上的差异已经非常小了，核心的JVM和API基本一致。现在，两者在功能上几乎可以说是等同的，主要的差异可能在于一些非核心的工具或特定平台下的安装程序。
• 支持和更新：
  • OpenJDK：
    • 更新主要由社区驱动，新特性和安全补丁会首先进入OpenJDK项目。
    • LTS（长期支持）版本的支持和更新通常由不同的供应商提供（如Adoptium/Eclipse Temurin, Red Hat, Amazon Corretto, Azul Zulu, Microsoft等）。这些供应商会基于OpenJDK源码构建自己的发行版，并提供特定周期的更新和支持。
  • Oracle JDK：
    • Oracle为其JDK提供商业支持服务（需要付费订阅）。
    • 对于LTS版本（如JDK 8, 11, 17, 21），Oracle会提供较长时间的公开更新（public updates），对于JDK 17+的LTS版本，这些公开更新是免费的。超出公开更新期限后，如果还需要补丁和支持，通常需要购买Oracle的商业支持。
• 性能：
  • 由于Oracle JDK和许多OpenJDK发行版都使用相同的HotSpot JVM核心代码，因此在大多数情况下，它们的性能表现基本一致。微小的性能差异可能来自于构建参数或包含的特定补丁，但对于绝大多数应用而言，这种差异可以忽略不计。

如何选择：

• 如果你需要JDK 17或更高版本的LTS JDK：
  • Oracle JDK (基于NFTC许可)：现在是一个非常好的选择，因为它是免费的，并且由Oracle直接提供较长时间的公开更新和支持。
  • OpenJDK发行版 (如 Eclipse Temurin, Amazon Corretto, Azul Zulu Community, Microsoft Build of OpenJDK等)：这些也是优秀的选择，它们完全免费，由可信的社区或公司维护，并提供LTS支持和及时的安全更新。选择哪个发行版可能取决于你对特定供应商的偏好、社区活跃度或特定的平台支持。
• 如果你需要JDK 11 到 JDK 16：
  • 生产环境：强烈推荐使用一个免费的 OpenJDK 发行版（如Eclipse Temurin, Amazon Corretto等），以避免Oracle JDK的商业许可费用。
  • 开发/测试环境：可以使用Oracle JDK（免费），但要注意如果部署到生产环境的限制。
• 如果你仍在使用JDK 8：
  • Oracle JDK (8u202之后)：用于生产需要商业许可（除非你有老的协议）。
  • OpenJDK 8 发行版 (如AdoptOpenJDK HotSpot/OpenJ9 - AdoptOpenJDK现在是Eclipse Adoptium项目下的Temurin, Corretto 8, Zulu 8等)：是继续免费使用JDK 8的推荐方式。
• 对商业支持有特定需求：
  • 如果你需要Oracle官方的商业支持和SLA，那么选择Oracle JDK并购买相应的支持服务是直接的途径。
  • 其他OpenJDK发行版的提供商（如Red Hat, Azul, Microsoft, Amazon）也为其各自的发行版提供商业支持。
• 关注点分离和避免供应商锁定：
  • 如果希望避免完全依赖单一供应商，或者希望在不同的OpenJDK发行版之间有更大的灵活性，那么选择一个广泛社区支持的OpenJDK发行版（如Eclipse Temurin）可能更合适。

总结：
对于大多数新项目或希望升级到最新LTS版本的用户，从JDK 17开始，Oracle JDK（凭借其新的NFTC免费许可）和主流的OpenJDK发行版（如Eclipse Temurin）都是非常好的选择，功能上基本没有区别。选择的关键更多在于你对许可的舒适度、对特定供应商的信任、是否需要商业支持以及更新策略的偏好。对于JDK 11-16，如果用于生产，则应优先选择免费的OpenJDK发行版。