1、概览 在 Spring Data 中，使用基于方法名称的派生查询来查询实体是很常见的。在处理实体之间的关系（如嵌套对象）时，Spring Data 提供了各种机制来检索这些嵌套对象中的数据。
本文将带你了解如何使用查询派生和 JPQL（Java 持久性查询语言）通过嵌套对象的属性进行查询。
2、场景概述 考虑一个有两个实体的简单场景：Customer 和 Order。每个 Order 都通过 ManyToOne（多对一）关系关联到一个 Customer。
我们要查找属于某个 Customer 的所有 Order，该 Customer 有特定的 email。在这种情况下，email 是 Customer 实体的属性，而我们的主要查询将在 Order 实体上执行。
实体示例如下：
@Entity @Table(name = "customers") public class Customer { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private String email; // Getter / Setter 省略 } @Entity @Table(name = "orders") public class Order { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private Date orderDate; @ManyToOne @JoinColumn(name = "customer_id") private Customer customer; // Getter / Setter 省略 } 3、使用派生查询 Spring Data JPA 允许开发者从 Repository 接口中的方法签名派生查询，从而简化了查询创建：
1、简介 虚拟线程是 JDK 21 中正式引入的一项杀手锏级别的功能，是提高应用程序性能、吞吐量的一种解决方案。
但是，JDK 没有内置的使用虚拟线程的任务调度器。因此，我们得自己编写使用虚拟线程运行的任务调度器。
本文将带你了解如何使用 Thread.sleep() 方法和 ScheduledExecutorService 类为虚拟线程创建自定义调度器。
2、虚拟线程是什么？ JEP-444 中引入了虚拟线程，作为线程类的轻量级版本，提高了应用程序的并发性和吞吐量。
虚拟线程占用的空间比通常的操作系统线程（或平台线程）要少得多。因此，我们可以在应用程序中同时产生比平台线程更多的虚拟线程。毫无疑问，这增加了并发单元的最大数量，也提高了应用程序的吞吐量。
关键的一点是，虚拟线程并不比平台线程更快（任务的耗时不会有改变）。在我们的应用中，虚拟线程的数量只比平台线程多，这样它们就能执行更多的并行工作。
虚拟线程的成本很低，因此我们不需要使用资源池等技术来为数量有限的线程安排任务。相反，我们可以在现代计算机中几乎无限地生成虚拟线程，而不会出现内存问题。
最后，虚拟线程是动态的，而平台线程的大小是固定的。因此，虚拟线程比平台线程更适合小型任务，如简单的 HTTP 或数据库调用。
3、虚拟线程调度 如上所述，虚拟线程的一大优势是体积小、成本低。我们可以在一个简单的机器中有效地生成数百万个虚拟线程，而不会出现内存不足的错误。因此，像使用平台线程、网络或数据库连接等更昂贵的资源那样池化虚拟线程并没有太大意义。
如果使用线程池，就会产生另一种开销，即为池中可用的线程调度任务，这将更加复杂，速度也可能更慢。此外，Java 中的大多数线程池都受到平台线程数的限制，而平台线程数总是小于程序中可能存在的虚拟线程数。
因此，我们必须避免使用带有线程池 API（如 ForkJoinPool 或 ThreadPoolExecutor）的虚拟线程。相反，我们应该始终为每个任务创建一个新的虚拟线程。
目前，Java 并没有提供使用虚拟线程进行调度的标准 API，就像我们使用其他并发 API（如 ScheduledExecutorService 的 schedule() 方法）一样。因此，为了有效地让虚拟线程运行计划任务，我们需要编写自己的 Scheduler（调度器）。
3.1、使用 Thread.sleep() 调度虚拟线程 创建自定义 Scheduler 的最直接方法是使用 Thread.sleep() 方法，让程序在当前线程执行时等待：
static Future<?> schedule(Runnable task, int delay, TemporalUnit unit, ExecutorService executorService) { return executorService.submit(() -> { try { Thread.sleep(Duration.of(delay, unit)); } catch (InterruptedException e) { Thread.
1、概览 处理 Date（日期）和 Time（时间）是许多 Java 应用程序的基本组成部分。多年来，Java 在处理日期方面不断发展，引入了更好的解决方案来简化开发者的工作。
2、传统的日期和时间处理类 在 java.time 包出现之前，Java 主要使用 Date 和 Calendar 类来处理日期。尽管它们现在也可以使用，但是有一些缺陷。
2.1、java.util.Date 类 java.util.Date 类是 Java 最初处理日期的解决方案，但它有一些缺点：
它是可变的，这意味着可能会遇到 线程安全 问题。 不支持时区。 它使用了令人困惑的方法名称和返回值，比如 getYear()，它返回的是自 1900 年以来的年数。 许多方法已废弃。 使用无参数构造函数创建 Date 对象，表示当前日期和时间（对象创建时）。
如下，实例化一个 Date 对象并打印其值：
Date now = new Date(); logger.info("Current date and time: {}", now); 这将输出当前日期和时间，如 Wed Sep 24 10:30:45 PDT 2024。虽然该构造函数仍然有效，但由于上述原因，这里不再建议新项目使用该构造函数。
2.2、java.util.Calendar 类 由于 Date 的局限性，Java 引入了 Calendar 类，对其进行了改进：
支持各种日历系统。 时区管理。 更加直观的日期操作方法。 我们可以使用 Calendar 操作日期。
Calendar cal = Calendar.
1、简介 Jakarta Persistence（前身为 JPA）是 Java 中对象关系映射的标准 API。它使开发人员能够在 Java 应用中管理关系数据，并通过使用注解和实体类将 Java 对象映射到数据库表来简化数据库交互。
本文将带你了解 Jakarta Persistence 3.2 中引入的一些关键新功能，重点介绍在配置、性能和可用性方面的改进。
2、Jakarta Persistence 3.2 是什么？ Jakarta Persistence 3.2 是 Jakarta Persistence API 的最新版本，它为 Java 应用中的对象关系映射（ORM）提供了一种标准化方法。
该版本改进了查询功能、性能和可用性，并增强了对现代数据库功能的支持。
要添加对 Jakarta Persistence 3.2 的支持，必须在 pom.xml 中添加以下 Maven 依赖：
<dependency> <groupId>jakarta.persistence</groupId> <artifactId>jakarta.persistence-api</artifactId> <version>3.2.0</version> </dependency> 此外，还需要支持该 API 的最新 Hibernate 7 版本：
<dependency> <groupId>org.hibernate.orm</groupId> <artifactId>hibernate-core</artifactId> <version>7.0.0.Beta1</version> </dependency> 3、关键的新功能 Jakarta Persistence 3.2 引入了一些新功能，以改进数据库连接处理、模式配置和事务管理。
3.1、持久化配置 最新的 Jakarta Persistence 3.2 版本添加了编程式 API，可使用 PersistenceConfiguration 类而不是传统的 persistence.
1、简介 尽管 OpenAPI 3.x 规范自 2017 年起就已发布，并经历了多次更新，但目前许多 API 仍在继续使用旧版本。
本文将带你了解 OpenAPI 2.0 和 OpenAPI 3.0 规范之间的主要区别，以及如何将 OpenAPI 2.0 规范转换为 OpenAPI 3.0。
2、OpenAPI 2.0 和 OpenAPI 3.0 简单回顾一下，OpenAPI 提供了一种标准格式，用于描述人类和机器都能读懂的 HTTP API。在 3.0 版之前，OpenAPI 被称为 Swagger 规范和 Swagger 工具包的一部分。从那时起，它已成为行业标准，并经过多次更新，带来了更多改进和功能。
与 2.0 相比，OpenAPI 3.0 引入了几项根本性变化。
首先，对整体结构进行了重构，以提高可重用性。添加了一个 components（组件）块来组织现有元素（如 schemas、responses、parameters）和新元素（请求 requestBody、examples 和 headers）。一些元素被重新命名 - definitions 现在被称为 schemas，securityDefinitions 被称为 securitySchemes。
此外，OpenAPI 3.0 还进一步扩展了 JSON Schema 功能。添加了 oneOf、anyOf 和 not 等关键字，以便对复杂的数据格式进行描述和灵活验证。
3.0 版本还引入了对 cookie 参数、内容类型协商和回调机制的支持。它还扩展了安全定义并简化了现有流程。
最后，你可以在官方 更新日志 中查看完整的变更列表。
1、概览 Secure Shell（SSH）允许我们安全地访问和管理远程系统，包括执行命令、传输文件和隧道服务。
我们可以通过 SSH 会话建立与远程 MySQL 数据库的连接。Java 有多个 SSH 客户端，其中最常见的是 Java Secure Channel（JSch）。
本文将带你了解如何通过 SSH 会话连接到运行在远程服务器上的 MySQL 数据库。
2、了解 SSH 端口转发 端口转发允许通过在 SSH 连接上将流量从本地端口重定向到远程服务器上的端口，从而实现客户系统和远程服务器之间的数据传输。
当防火墙或其他限制阻止直接连接远程服务器的 IP 和端口时，这一点尤其有用。
在本例中，MySQL 服务器运行在远程服务器的 localhost 上，通常使用 3306 端口。虽然从技术上讲，可以直接连接到远程服务器的 IP 和 MySQL 端口，但出于安全考虑，这通常会受到限制（3306 端口未开放）。相反，我们可以通过 SSH 使用本地端口转发来建立与数据库的安全连接。
在本地端口转发中，我们在本地机器上分配一个可用端口，并将其与远程运行的 MySQL 服务器端口绑定，以允许我们的程序与远程服务器之间进行数据通信。
3、Maven 依赖 首先，在 pom.xml 中添加 JSch 和 MySQL 驱动依赖：
<dependency> <groupId>com.github.mwiede</groupId> <artifactId>jsch</artifactId> <version>0.2.20</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <version>9.0.0</version> </dependency> JSch 提供了 Session 等类，这些类对于建立与远程服务器的 SSH 连接至关重要。此外，MySQL 驱动允许我们与运行中的 MySQL 服务器建立连接。
1、概览 Java 数据库连接（JDBC）应用编程接口（API）提供了一系列类和接口。我们可以使用它们连接关系数据库等数据源并运行 SQL 语句。
以流行的 MYSQL 为例，当我们需要连接到 MySQL 时，就需要使用 MySQL 数据库的专用 JDBC 驱动程序： com.mysql.cj.jdbc.Driver，该驱动实现了 JDBC API。
在运行 SQL 语句时，我们可能会遇到异常：“com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Data too long for column”。
本文将带你了解出现此异常的原因，以及解决办法。
2、Schema 设置 首先，创建如下关系表 department：
DESC department; +-------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | name | varchar(50) | YES | | NULL | | | code | varchar(4) | YES | | NULL | | +-------+-------------+------+-----+---------+-------+ 注意，code 列定义只允许使用大小为 4 或更小的 varchar。
1、概览 签署（也叫做签发）证书签名请求（CSR）是密码学中的一项常见操作。本文将带你了解如何使用 Bouncy Castle 签署 CSR。
2、签署 CSR 签署 CSR 是证书颁发机构（CA）验证 CSR 中的信息并颁发证书的过程。CA 使用其私钥签署证书。签名后的证书可在客户端和服务器之间建立安全连接。
要使用 Bouncy Castle 签署 CSR，需要执行几个基本步骤：
生成可信实体 CA 证书和私钥。 生成证书签名请求（CSR）。 使用 CA 证书和私钥签署 CSR。 3、设置 首先，需要在 pom.xml 中添加 Bouncy Castle 依赖：
<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcpkix-jdk18on</artifactId> <version>1.76</version> </dependency> 接下来，需要创建一个 SecurityProvider 类来注册 Bouncy Castle Provider：
static { Security.addProvider(new BouncyCastleProvider()); } 4、使用 Bouncy Castle 签署 CSR 使用 Bouncy Castle 签署 CSR 需要几个步骤。
4.1、生成可信实体 CA 证书和私钥 CA 是向客户签发证书的可信实体。我们必须生成 CA 证书和私钥来签署 CSR。
先生成一个密钥对：
1、概览 本文将带你了解 Java 中 interface（接口）和 @interface（注解接口）的区别以及它们的应用。
interface是一个类实现的规范。在最常见的形式中，它是一组相关方法，这些方法没有具体的实现。
而 @interface 则允许你在代码中添加元数据。编译器、工具或框架使用这些元数据来影响类的行为或处理过程。
2、interface interface 是一种规范。它规定了实现类必须实现的行为，但没有规定如何实现。它表明，任何实现接口的类都必须为接口的所有方法提供具体的实现。
public interface Animal { String eat(); String sleep(); } public class Dog implements Animal { @Override public String eat() { return "Dog is eating"; } @Override public String sleep() { return "Dog is sleeping"; } } 接口的所有方法都是默认 public 和 abstract 的（default 方法和 static 方法除外），所有字段都是 public、static 和 final 的。在 Java 中，我们可以使用接口实现抽象、多重继承和松散耦合。
抽象：接口只定义了调用方法所需的基本信息，而实现方法的复杂性则被隐藏起来。
多重继承：一个类可以实现多个接口，从而避免了在允许类多重继承的语言中可能出现的 “菱形继承” 问题。
松耦合：接口在功能和实现细节之间提供了明显的分离。由于我们对方法和签名进行了单独定义，它使一个类可以改变其内部流程，而不影响其用户。
3、@interface 在Java中，我们使用 @interface 来声明注解类型。注解提供了一种向 Java 代码元素（如类、方法和字段）添加元数据的方式。因此，工具和库可以利用这些元数据在编译过程或运行时收集信息，以进行代码处理。
1、简介 Apache Kafka 是一个功能强大的分布式流平台，被广泛用于构建实时数据管道和流应用。然而，Kafka 在运行过程中可能会遇到各种异常和错误。其中一个常见的异常就是 InstanceAlreadyExistsException。
本文将带你了解 Kafka 出现 InstanceAlreadyExistsException 异常的原因和解决办法。
2、InstanceAlreadyExistsException 异常是什么？ InstanceAlreadyExistsException 是 java.lang.RuntimeException 的子类。在 Kafka 的上下文中，这个异常通常在尝试创建具有与现有生产者或消费者相同的 Client ID 的 Kafka 生产者或消费者时出现。
每个 Kafka 客户端实例都有一个唯一的 Client ID，它对 Kafka 集群内的元数据跟踪和客户端连接管理至关重要。如果试图创建一个新的客户端实例，而 Client ID 已被现有客户端使用，Kafka 会抛出 InstanceAlreadyExistsException（实例已存在异常）。
3、内部机制 虽然我们提到 Kafka 会抛出这个异常，但值得注意的是，Kafka 通常会在其内部机制中优雅地处理这个异常。通过在内部处理异常，Kafka 可以将问题隔离和限制在其自身的子系统中。这可以防止异常影响主线程，并潜在地导致更广泛的系统不稳定或停机。
在 Kafka 的内部实现中，registerAppInfo() 方法通常在初始化 Kafka 客户端（生产者或消费者）时被调用。假设现有的客户端有相同的 client.id，该方法会捕获 InstanceAlreadyExistsException。由于异常是在内部处理的，它不会被抛到主线程上，而人们可能希望在主线程上捕获异常。
4、InstanceAlreadyExistsException 的原因 在本节中，我们将通过代码示例来研究导致 InstanceAlreadyExistsException 的各种情况。
4.1、消费者组中重复的 Client ID Kafka 规定同一消费者组内的消费者有不同的 Client ID。当一个组内的多个消费者共享相同的 Client ID 时，Kafka 的消息传递语义可能会变得不可预测。这会干扰 Kafka 管理偏移量和维护消息顺序的能力，可能导致消息重复或丢失。因此，当多个消费者共享同一个 Client ID 时，就会触发该异常。
