• 浅拷贝是指只复制对象本身和其内部的值类型字段，但不会复制对象内部的引用类型字段。换句话说，浅拷贝只是创建一个新的对象，然后将原对象的字段值复制到新对象中，但如果原对象内部有引用类型的字段，只是将引用复制到新对象中，两个对象指向的是同一个引用对象。
• 深拷贝是指在复制对象的同时，将对象内部的所有引用类型字段的内容也复制一份，而不是共享引用。换句话说，深拷贝会递归复制对象内部所有引用类型的字段，生成一个全新的对象以及其内部的所有对象。

• 实现 Cloneable 接口并重写 clone() 方法。这种方法要求对象及其所有引用类型字段都实现 Cloneable 接口，并且重写 clone() 方法。在 clone() 方法中，通过递归克隆引用类型字段来实现深拷贝。
• 使用序列化和反序列化。通过将对象序列化为字节流，再从字节流反序列化为对象来实现深拷贝。要求对象及其所有引用类型字段都实现 Serializable 接口。
• 手动递归复制。针对特定对象结构，手动递归复制对象及其引用类型字段。适用于对象结构复杂度不高的情况。

 泛型是 Java 编程语言中的一个重要特性，它允许类、接口和方法在定义时使用一个或多个类型参数，这些类型参数在使用时可以被指定为具体的类型。
 泛型的主要目的是在编译时提供更强的类型检查，并且在编译后能够保留类型信息，避免了在运行时出现类型转换异常。

• 使用 new 关键字。
• 使用 Class 类的 newInstance() 方法。
• 使用 Constructor 类的 newInstance() 方法。
• 使用 clone() 方法。
• 使用反序列化。

 由 Java 的垃圾回收器（Garbage Collector）负责回收。垃圾回收器的工作是在程序运行过程中自动进行的，它会周期性地检测不再被引用的对象，并将其回收释放内存。
 具体来说，Java 对象的回收时机是由垃圾回收器根据一些算法来决定的，主要有以下几种情况。

1. 引用计数法：某个对象的引用计数为 0 时，表示该对象不再被引用，可以被回收。
2. 可达性分析算法：从根对象（如方法区中的类静态属性、方法中的局部变量等）出发，通过对象之间的引用链进行遍历，如果存在一条引用链到达某个对象，则说明该对象是可达的，反之不可达，不可达的对象将被回收。
3. 终结器（Finalizer）：如果对象重写了 finalize() 方法，垃圾回收器会在回收该对象之前调用 finalize() 方法，对象可以在 finalize() 方法中进行一些清理操作。然而，终结器机制的使用不被推荐，因为它的执行时间是不确定的，可能会导致不可预测的性能问题。注意 finalize() 复杂的特性，高版本 JDK 已经移除该方法。

 在 Java 中，私有对象通常指的是类中被声明为 private 的成员变量或方法。由于 private 访问修饰符的限制，这些成员只能在其所在的类内部被访问。
 不过，可以通过下面两种方式来间接获取私有对象。

• 使用公共访问器方法（getter 方法）：如果类的设计者遵循良好的编程规范，通常会为私有成员变量提供公共的访问器方法（即 getter 方法），通过调用这些方法可以安全地获取私有对象。
• 反射机制。反射机制允许在运行时检查和修改类、方法、字段等信息，通过反射 Field.setAccessible(true) 可以绕过 private 访问修饰符的限制来获取私有对象。

 Java 反射机制是在运行状态中，对于任意一个类，都能够知道这个类中的所有属性和方法，对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为 Java 语言的反射机制。
 反射具有以下特性。

• 运行时类信息访问：反射机制允许程序在运行时获取类的完整结构信息，包括类名、包名、父类、实现的接口、构造函数、方法和字段等。
• 动态对象创建：可以使用反射 API 动态地创建对象实例，即使在编译时不知道具体的类名。这是通过 Class 类的 newInstance() 方法或 Constructor 对象的 newInstance() 方法实现的。
• 动态方法调用：可以在运行时动态地调用对象的方法，包括私有方法。这通过 Method 类的 invoke() 方法实现，允许你传入对象实例和参数值来执行方法。
• 访问和修改字段值：反射还允许程序在运行时访问和修改对象的字段值，即使是私有的。这是通过 Field 类的 get() 和 set() 方法完成的。

• 加载数据库驱动。
• 配置文件加载。典型的就是 SPI 机制会使用。
• SpringBoot 自动装配。底层使用了 Class.forName("xx") 判断类是否存在。

 注解本质是一个继承了 Annotation 的特殊接口，其具体实现类是 Java 运行时生成的动态代理类。
 我们通过反射获取注解时，返回的是 Java 运行时生成的动态代理对象。通过代理对象调用自定义注解的方法，会最终调用 AnnotationInvocationHandler 的 invoke 方法。该方法会从 memberValues 这个 Map 中索引出对应的值。而 memberValues 的来源是 Java 常量池。

 注解本质上是一种特殊的接口，它继承自 java.lang.annotation.Annotation 接口，所以注解也叫声明式接口，例如，定义一个简单的注解。

public @interface MyAnnotation{
    String value();
}

 编译后，Java 编译器会将其转换为一个继承自 Annotation 的接口，并生成相应的字节码文件。
 根据注解的作用范围，Java 注解可以分为以下几种类型。

• 源码级别注解：仅存在于源码中，编译后不会保留 (@Retention(RetentionPolicy.SOURCE))。
• 类文件级别注解：保留在 .class 文件中，但运行时不可见 (@Retention(RetentionPolicy.CLASS))。
• 运行时注解：保留在 .class 文件中，并且可以通过反射在运行时访问 (@Retention(RetentionPolicy.RUNTIME))。

 只有运行时注解可以通过反射机制进行解析。当注解被标记为 RUNTIME 时，Java 编译器会在生成的 .class 文件中保存注解信息。这些信息存储在字节码的属性表（Attribute Table）中，具体包括以下内容。

• RuntimeVisibleAnnotations：存储运行时可见的注解信息。
• RuntimeInvisibleAnnotations：存储运行时不可见的注解信息。
• RuntimeVisibleParameterAnnotations 和 RuntimeInvisibleParameterAnnotations：存储方法参数上的注解信息。

 通过工具（如 javap -v）可以查看 .class 文件中的注解信息。
 注解的解析主要依赖于 Java 的反射机制。以下是解析注解的基本流程。
(1) 获取注册信息：通过反射 API 可以获取类、方法、字段等元素上的注解。例如。

Class<?> class = MyClass.class;
MyAnnotation annotation = class.getAnnotation(MyAnnotation.class);
if(annotation != null){
    // 
}

(2) 底层原理：反射机制的核心类是 java.lang.reflect.AnnotatedElement，它是所有可以被注解修饰的元素（如 Class、Method、Field 等）的父接口。该接口提供了以下方法。

• getAnnotation(Class<T> annotationClass)：获取指定类型的注解。
• getAnnotations()：获取所有注解。
• isAnnotationPresend(Class<? extends Annotation> annotationClass)：判断是否包含指定注解。

 这些方法的底层实现依赖于 JVM 提供的本地方法(Class 类的方法)，例如。

• native Annotation[] getDeclareAnnotations0(boolean publicONly);
• native <A extend Annotation> A getAnnotation(Class<A> annotationClass);

 JVM 在加载类时会解析 .class 文件中的注解信息，并将其存储在内存中，供反射机制使用。
 因此，注解解析的底层实现主要依赖于 Java 的反射机制和字节码文件的存储。通过 @Retention 元注解可以控制注解的保留策略，当使用 RetentionPolicy.RUNTIME 时，可以在运行时通过反射 API 来解析注解信息。在 JVM 层面，会从字节码文件中读取注解信息，并创建注解的代理对象来获取注解的属性值。

 注解的作用域（Scope）指的是注解可以应用在哪些程序元素上，例如类、方法、字段等。Java 注解的作用域可以分为三种。

• 类级别作用域：用于描述类的注解，通常放置在类定义的上面，可以用来指定类的一些属性，如类的访问级别、继承关系、注释等。
• 方法级别作用域：用于描述方法的注解，通常放置在方法定义的上面，可以用来指定方法的一些属性，如方法的访问级别、返回值类型、异常类型、注释等。
• 字段级别作用域：用于描述字段的注解，通常放置在字段定义的上面，可以用来指定字段的一些属性，如字段的访问级别、默认值、注释等。

 除了这三种作用域，Java 还提供了其他一些注解作用域，例如构造函数作用域和局部变量作用域。这些注解作用域可以用来对构造函数和局部变量进行描述和注释。

 Java 的异常体系主要基于两大类：Throwable 类及其子类。Throwable 有两个重要的子类：Error 和 Exception，它们分别代表了不同类型的异常情况。

• Error（错误）：表示运行时环境的错误。错误是程序无法处理的严重问题，如系统崩溃、虚拟机错误、动态链接失败等。通常，程序不应该尝试捕获这类错误。例如，OutOfMemoryError、StackOverflowError 等。
• Exception（异常）：表示程序本身可以处理的异常条件。异常分为两大类。
  • 非运行时异常：这类异常在编译时期就必须被捕获或者声明抛出。它们通常是外部错误，如文件不存在（FileNotFoundException）、类未找到（ClassNotFoundException）等。非运行时异常强制程序员处理这些可能出现的问题，增强了程序的健壮性。
  • 运行时异常：这类异常包括运行时异常（RuntimeException）和错误（Error）。运行时异常由程序错误导致，如空指针访问（NullPointerException）、数组越界（ArrayIndexOutOfBoundsException）等。运行时异常是不需要在编译时强制捕获或声明的。

 异常处理是通过使用 try-catch 语句块来捕获和处理异常。以下是 Java 中常用的异常处理方式。

• try-catch 语句块：用于捕获并处理可能抛出的异常。try 块中包含可能抛出异常的代码，catch 块用于捕获并处理特定类型的异常。可以有多个 catch 块来处理不同类型的异常。
• throw 语句：用于手动抛出异常。可以根据需要在代码中使用 throw 语句主动抛出特定类型的异常。
• throws 关键字：用于在方法声明中声明可能抛出的异常类型。如果一个方法可能抛出异常，但不想在方法内部进行处理，可以使用 throws 关键字将异常传递给调用者来处理。
• finally 块：用于定义无论是否发生异常都会执行的代码块。通常用于释放资源，确保资源的正确关闭。

 如果异常是未检查异常或者在方法内部被捕获和处理了，那么就不需要使用 throws。

• Unchecked Exceptions：未检查异常（unchecked exceptions）是继承自 RuntimeException 类或 Error 类的异常，编译器不强制要求进行异常处理。因此，对于这些异常，不需要在方法签名中使用 throws 来声明。示例包括 NullPointerException、ArrayIndexOutOfBoundsException 等。
• 捕获和处理异常：另一种常见情况是，在方法内部捕获了可能抛出的异常，并在方法内部处理它们，而不是通过 throws 子句将它们传递到调用者。这种情况下，方法可以处理异常而无需在方法签名中使用 throws。

 try 块中的代码将按顺序执行，如果抛出异常，将在 catch 块中进行匹配和处理，然后程序将继续执行 catch 块之后的代码。如果没有匹配的 catch 块，异常将被传递给上一层调用的方法。

 try-return-a-finally-return-b- 这条语句返回啥？
 finally 块中的 return 语句会覆盖 try 块中的 return 返回，因此，该语句将返回 "b"。

• JVM 层面保障​​：JVM 在 try 或 catch 块结束后，会强制检查并执行 finally 块。
  ​* ​字节码层面​​：编译后的代码会在 try 和 catch 块的末尾插入对 finally 块的调用指令。

 Object 忽略重载和类似方法，主要有 6 个方法，类主要结构如下。

public class Object {
    public native int hashCode();

    public boolean equals(Object obj) {
        return (this == obj);
    }

    protected native Object clone() throws CloneNotSupportedException;

    public String toString() {
        return getClass().getName() + "@" + Integer.toHexString(hashCode());
    }

    public final native void notify();

    public final native void notifyAll();

    public final native void wait(long timeout) throws InterruptedException;

    /**
     * JDK9 被标记为 @Deprecated
     * JDK18 明确说要弃用该方法
     */
    protected void finalize() throws Throwable { }
}

 自反性、对称性、传递性、一致性、与null的比较

 使用场景。

• 基本数据类型：必须用 ==（equals() 不能用于基本类型）。
• 引用类型。若需判断是否为同一个对象（如单例模式），用 ==；若需判断内容是否相等（如字符串、集合等），用 equals()。

 简单来说区别如下。

• == 是“物理相等”，直接比较值或内存地址。
• equals() 是“逻辑相等”，需依赖具体实现，通常用于内容比较。

 注意事项。

• 重写 equals() 必须同时重写 hashCode()。（否则在使用 HashMap、HashSet 等哈希结构时会出现问题）。
• 避免空指针：调用 equals() 时，推荐使用 Objects.equals(a, b)（Java 7+）。

 在 Java 中，对于重写 equals 方法的类，通常也需要重写 hashCode 方法，并且需要遵循以下规定。

• 一致性：如果两个对象使用 equals 方法比较结果为 true，那么它们的 hashCode 值必须相同。也就是说，如果 obj1.equals(obj2) 返回 true，那么 obj1.hashCode() 必须等于 obj2.hashCode()。
• 非一致性：如果两个对象的 hashCode 值相同，它们使用 equals 方法比较的结果不一定为 true。即 obj1.hashCode() == obj2.hashCode() 时，obj1.equals(obj2) 可能为 false ，这种情况称为哈希冲突。

 hashCode 和 equals 方法是紧密相关的，重写 equals 方法时必须重写 hashCode 方法，以保证在使用哈希表等数据结构时，对象的相等性判断和存储查找操作能够正常工作。而重写 hashCode 方法时，需要确保相等的对象具有相同的哈希码，但相同哈希码的对象不一定相等。

 即不可变需求用 String，可变且线程安全用 StringBuffer，可变且高性能用 StringBuilder。

• 重写 hashCode() 方法可能引起的内存溢出问题open in new window
• String hashCode 重复open in new window

• 使用序列化和反序列化：将对象序列化为字节流，并将其发送到另一个 JVM，然后在另一个 JVM 中反序列化字节流恢复对象。这可以通过 Java 的 ObjectOutputStream 和 ObjectInputStream 来实现。
• 使用消息传递机制：利用消息传递机制，比如使用消息队列（如 RabbitMQ、Kafka）或者通过网络套接字进行通信，将对象从一个 JVM 发送到另一个。这需要自定义协议来序列化对象并在另一个 JVM 中反序列化。
• 使用远程方法调用（RPC）：可以使用远程方法调用框架，如 gRPC，来实现对象在不同 JVM 之间的传输。远程方法调用可以让你在分布式系统中调用远程 JVM 上的对象的方法。
• 使用共享数据库或缓存：将对象存储在共享数据库（如 MySQL、PostgreSQL）或共享缓存（如 Redis）中，让不同的 JVM 可以访问这些共享数据。这种方法适用于需要共享数据但不需要直接传输对象的场景。

 Java 默认的序列化虽然实现方便，但却存在安全漏洞、不跨语言以及性能差等缺陷。

• 无法跨语言： Java 序列化目前只适用基于 Java 语言实现的框架，其它语言大部分都没有使用 Java 的序列化框架，也没有实现 Java 序列化这套协议。因此，如果是两个基于不同语言编写的应用程序相互通信，则无法实现两个应用服务之间传输对象的序列化与反序列化。
• 容易被攻击：Java 序列化是不安全的，我们知道对象是通过在 ObjectInputStream 上调用 readObject() 方法进行反序列化的，这个方法其实是一个神奇的构造器，它可以将类路径上几乎所有实现了 Serializable 接口的对象都实例化。这也就意味着，在反序列化字节流的过程中，该方法可以执行任意类型的代码，这是非常危险的。
• 序列化后的流太大：序列化后的二进制流大小能体现序列化的性能。序列化后的二进制数组越大，占用的存储空间就越多，存储硬件的成本就越高。如果我们是进行网络传输，则占用的带宽就更多，这时就会影响到系统的吞吐量。

 我会考虑用主流序列化框架，比如 Jackson、Protobuf 来替代 Java 序列化。
 如果追求性能的话，Protobuf 序列化框架会比较合适，Protobuf 的这种数据存储格式，不仅压缩存储数据的效果好， 在编码和解码的性能方面也很高效。Protobuf 的编码和解码过程结合 .proto 文件格式，加上 Protocol Buffer 独特的编码格式，只需要简单的数据运算以及位移等操作就可以完成编码与解码。可以说 Protobuf 的整体性能非常优秀。

 其实，像序列化和反序列化，无论这些可逆操作是什么机制，都会有对应的处理和解析协议，例如加密和解密，TCP 的粘包和拆包，序列化机制是通过序列化协议来进行处理的，和 class 文件类似，它其实是定义了序列化后的字节流格式，然后对此格式进行操作，生成符合格式的字节流或者将字节流解析成对象。
 在 Java 中通过序列化对象流来完成序列化和反序列化。

• ObjectOutputStream：通过 writeObject() 方法做序列化操作。
• ObjectInputStrean：通过 readObject() 方法做反序列化操作。

 只有实现了 Serializable 或 Externalizable 接口的类的对象才能被序列化，否则抛出异常！
 参考 Serializable/Externalizable 序列化接口open in new window。

 使用 volatile 和 sychronized 实现单例模式，注意使用了双重检查锁。
 示例代码略。

 目的不同：代理模式主要关注控制对对象的访问，而适配器模式则用于接口转换，使不兼容的类能够一起工作。
 结构不同：代理模式一般包含抽象主题、真实主题和代理三个角色，适配器模式包含目标接口、适配器和被适配者三个角色。
 应用场景不同：代理模式常用于添加额外功能或控制对对象的访问，适配器模式常用于让不兼容的接口协同工作。

 同步、异步针对请求，阻塞，非阻塞针对客户端。

 可以用 Java NIO，是一种同步非阻塞的 I/O 模型，也是 I/O 多路复用的基础。
 传统的 BIO 里面 socket.read()，如果 TCP RecvBuffer 里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据， 如果使用 BIO 要想要并发处理多个客户端的 IO，那么会使用多线程模式，一个线程专门处理一个客户端 IO，这种模式随着客户端越来越多，所需要创建的线程也越来越多，会急剧消耗系统的性能。
 NIO 是基于 I/O 多路复用实现的，它可以只用一个线程处理多个客户端 I/O，如果你需要同时管理成千上万的连接，但是每个连接只发送少量数据，例如一个聊天服务器，用 NIO 实现会更好一些。

 选择建议。

• 传统阻塞 I/O：适合简单的客户端应用或连接数少的服务端应用。
• NIO 多路复用：适合高并发的中间件和服务器(如 Netty)。
• 异步 I/O：适合需要极致性能的场景，但要注意平台兼容性。
• Java 的 I/O 模型选择取决于应用场景、性能需求和开发复杂度等因素。现代高并发应用通常倾向于使用 NIO 多路复用或异步 I/O 模型。

• BIO（blocking IO）：就是传统的 java.io 包，它是基于流模型实现的，交互的方式是同步、阻塞方式，也就是说在读入输入流或者输出流时，在读写动作完成之前，线程会一直阻塞在那里，它们之间的调用是可靠的线性顺序。优点是代码比较简单、直观；缺点是 IO 的效率和扩展性很低，容易成为应用性能瓶颈。
• NIO（non-blocking IO） ：Java 1.4 引入的 java.nio 包，提供了 Channel、Selector、Buffer 等新的抽象，可以构建多路复用的、同步非阻塞 IO 程序，同时提供了更接近操作系统底层高性能的数据操作方式。
• AIO（Asynchronous IO） ：是 Java 1.7 之后引入的包，是 NIO 的升级版本，提供了异步非堵塞的 IO 操作方式，所以人们叫它 AIO（Asynchronous IO），异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

 NIO 是一种同步非阻塞的 IO 模型，所以也可以叫 NON-BLOCKINGIO。同步是指线程不断轮询 IO 事件是否就绪，非阻塞是指线程在等待 IO 的时候，可以同时做其他任务。
 同步的核心就 Selector（I/O多路复用），Selector 代替了线程本身轮询 IO 事件，避免了阻塞同时减少了不必要的线程消耗；非阻塞的核心就是通道和缓冲区，当 IO 事件就绪时，可以通过写到缓冲区，保证 IO 的成功，而无需线程阻塞式地等待。
 NIO 由一个专门的线程处理所有 IO 事件，并负责分发。事件驱动机制，事件到来的时候触发操作，不需要阻塞的监视事件。线程之间通过 wait,notify 通信，减少线程切换。
 NIO 主要有三大核心部分：Channel(通道)，Buffer(缓冲区), Selector。传统 IO 基于字节流和字符流进行操作，而 NIO 基于 Channel 和 Buffer(缓冲区)进行操作，数据总是从通道读取到缓冲区中，或者从缓冲区写入到通道中。

 Netty 的 I/O 模型是基于非阻塞 I/O 实现的，底层依赖的是 NIO 框架的多路复用器 Selector。采用 epoll 模式后，只需要一个线程负责 Selector 的轮询。当有数据处于就绪状态后，需要一个事件分发器（Event Dispather），它负责将读写事件分发给对应的读写事件处理器（Event Handler）。事件分发器有两种设计模式：Reactor 和 Proactor，Reactor 采用同步 I/O， Proactor 采用异步 I/O。
 Reactor 实现相对简单，适合处理耗时短的场景，对于耗时长的 I/O 操作容易造成阻塞。Proactor 性能更高，但是实现逻辑非常复杂，适合图片或视频流分析服务器，目前主流的事件驱动模型还是依赖 select 或 epoll 来实现。