技术博客

...

我们经常听到一个说法：“我的应用变慢了，加点线程吧！”。在多核心CPU普及的今天，“多线程”似乎成了提升性能的万能药。然而，它真的是吗？ 这篇博文的目的，是带你暂时忘掉 Thread, Runnable, ExecutorService 这些熟悉的API，戴上一副特殊的“眼镜”，从计算机最核心的部件——CPU的视角，去重新审视我们习以为常的多线程世界。你会发现，我们追求的从来不是“更多的线程”，而是一种更高效的“工作模式”。 第一章：CPU眼中的两种“工作”——计算与等待想象一下你是CPU，是这个系统里唯一真正能“思考”和“执行”的角色。交到你手上的任务，在你看来，只有两种截然不同的性质： CPU密集型任务 (CPU-Bound) 这是什么？ 这类任务需要你持续不断地进行高速计算。比如：视频编码、大规模数据排序、复杂的科学计算。 你的状态： “全神贯注”。你的计算单元在满负荷运转，几乎没有喘息之机。 类比： 一位数学家，拿着纸笔，在一间安静的房间里，心无旁骛地推导一个复杂的公式。整个过程，他都在思考和书写，没有停顿。 I/O密集型任务...

在现代Java应用中，CompletableFuture 是构建响应式、高吞吐量系统的利器。然而，许多开发者在使用其强大的链式调用功能时，常常在 thenApply 和 thenCompose 之间感到困惑。这不仅仅是API选择的问题，错误的选用可能导致系统在并发压力下性能断崖式下跌。 本文的目标，不仅仅是告诉你“何时用哪个”，而是要带你深入问题的本质： 核心误区：我们通常认为的“线程在等待”，究竟是一种怎样的状态？ 底层原理：CompletableFuture...

在学习和使用 Java 的 CompletableFuture 进行异步编程时，很多开发者都可能遇到一个令人困惑的场景：在 main 方法中满怀信心地提交了一个耗时任务，结果程序一闪而过，预期的异步结果却迟迟没有出现。这背后究竟隐藏着什么秘密？ 本文将从一个典型的“踩坑”案例出发，层层深入，为您揭示 CompletableFuture 与 JVM 线程模型之间的微妙关系，并最终给出一套健壮的解决方案。 现象：一闪而过的异步任务让我们从一个常见的场景开始：异步查询用户信息，然后根据结果发送短信。 场景描述: 异步执行一个模拟的耗时操作（比如查询用户手机号，耗时3秒）。 操作成功后，获取结果（手机号）。 使用该结果执行下一步操作（发送短信）。 初始代码： 123456789101112131415161718192021222324252627282930313233import java.util.concurrent.CompletableFuture;import java.util.concurrent.TimeUnit;public class...

在Java 8之前，进行异步编程通常意味着与Future接口和回调函数打交道，这往往会导致代码结构复杂，难以维护，即所谓的“回调地狱”。Java 8引入的CompletableFuture彻底改变了这一局面，它不仅提供了强大的异步编程能力，更带来了一种流式、声明式的编程范式。 本文将深入探讨CompletableFuture的核心优势，通过与传统多线程写法的对比，揭示其解决了哪些痛点。同时，我们也会剖析它的能力边界，明确在现代并发编程中，哪些职责仍需我们亲力亲为。 场景引入：构建一个聚合页面假设我们正在开发一个电商应用的首页，需要同时异步加载三部分数据： 获取用户信息 获取推荐商品列表（独立任务） 获取用户订单列表（依赖用户信息） 最后，将这三部分数据聚合起来展示。这个场景包含了并行和串行依赖，是检验异步编程模型的绝佳试金石。 一、传统方式的挣扎：ExecutorService 与...

在 Java 异步编程的世界里，CompletableFuture 是一个无法绕开的强大工具。当我们启动一个异步任务后，最终总要获取它的结果。这时，join() 和 get() 两个方法就登场了。它们都能阻塞当前线程直到异步任务完成并返回结果，但它们之间存在一个关键且重要的区别，这个区别直接影响了代码的简洁性和使用场景。 一言以蔽之：get() 抛出受检异常，join() 抛出非受检异常。 让我们深入探讨这个核心差异。 1. 核心区别：异常处理机制get() 方法：传统的异常处理get() 方法继承自 java.util.concurrent.Future 接口，它的设计遵循了 Java 传统的异常处理模型，即抛出受检异常（Checked Exceptions）。这意味着当你调用 get() 时，编译器会强制你处理两种可能发生的异常： ExecutionException: 如果异步任务在执行过程中内部抛出了异常，这个异常会被包装在 ExecutionException 中抛出。你需要通过 e.getCause()...

1. 为什么需要 CompletableFuture？在 CompletableFuture 出现之前，Java 5 引入了 Future 接口，用于表示一个异步计算的结果。但 Future 的能力非常有限： 无法主动完成：你无法手动将一个 Future 标记为已完成，并设置其结果。它只能被动地等待执行它的线程完成任务。 阻塞式获取结果：future.get() 方法是阻塞的，调用时会暂停当前线程，直到异步任务完成。这违背了异步编程的初衷。 没有回调机制：你无法在 Future 完成时自动触发某个动作（回调函数），只能通过循环调用 isDone() 来检查，或者直接阻塞在 get() 上。 无法组合：你很难将多个 Future 串联起来，例如当一个 Future 完成后，用其结果去执行另一个异步任务。 CompletableFuture 扩展了 Future 接口，并实现了 CompletionStage 接口，彻底解决了以上痛点。它为异步编程提供了一种功能强大、非阻塞、可组合的范式，是现代 Java 异步编程的基石。 核心思想：CompletableFuture...

欢迎来到 Pekko 的世界！本教程将通过一个具体的示例，向您展示如何使用 Pekko 构建一个简单的分布式应用程序。我们将创建两个独立的 Java 应用：一个”远程系统”（服务端），它会等待请求；以及一个”客户端”，它会向远程系统发送一个问候请求，并异步地等待回复。 这个过程主要利用了 Pekko 中非常重要的 Ask 模式 (Ask Pattern)。 源码: github, gitee 核心概念简介在深入代码之前，我们先了解几个 Pekko 的核心概念： Actor (演员): Actor 是 Pekko 的基本计算单元。它是一个对象，封装了状态（State）和行为（Behavior）。Actor 之间通过发送异步消息进行通信，这是它们唯一的通信方式。每个 Actor 都有一个”邮箱”（Mailbox）用来接收消息。 ActorSystem (演员系统): 这是一个重量级的结构，是所有 Actor 的家。它管理着 Actor 的生命周期、调度、配置和线程池等资源。一个应用程序通常只有一个 ActorSystem。 Message (消息): Actor...

前言欢迎来到 Pekko 的世界！Pekko 是 Akka 的一个社区驱动的分支，它继承了 Akka 强大的 Actor 模型，为构建高并发、分布式和弹性系统提供了坚实的基础。在 Actor 模型中，所有通信都是通过消息传递完成的。 本篇博文将作为 Pekko 入门系列的第一篇，重点介绍最核心、最常用的消息传递模式：tell。我们将通过构建一个简单的客户端-服务端（Client-Server）应用，一步步向您展示如何使用 tell 方法进行异步、非阻塞的“发射后不管”（Fire-and-Forget）通信。 源码：github, gitee 项目准备在开始编码之前，我们需要在 Maven 项目中添加 Pekko 相关的依赖。 pom.xml 我们主要需要以下几个核心依赖： pekko-actor: Pekko 的核心 Actor 模块。 pekko-remote: 用于实现 Actor 之间的远程通信。 pekko-serialization-jackson: 一个高效且安全的序列化模块，我们将用它替代 Java 原生序列化。 pekko-slf4j:...

Apache Flink 作为业界领先的流处理和批处理统一计算引擎，其强大的功能与复杂的内部机制吸引了无数开发者深入探索。对于后端开发者而言，能够直接在本地 IDE 中调试 Flink 源码，无疑是提升理解、快速定位问题、甚至参与社区贡献的利器。然而，搭建这样一个庞大项目的本地调试环境，尤其是特定版本如 Flink 1.18，往往涉及到诸多配置细节，令不少初学者望而却步。本篇博文旨在提供一份详尽的、按部就班的指南，帮助您在 Windows 系统下，使用 IntelliJ IDEA 顺利搭建起 Flink 1.18 的源码调试环境。通过本文的指引，您将能够轻松配置项目、编译源码，并成功启动一个可供调试的本地 Flink Standalone 集群，为您的 Flink 深度学习之旅奠定坚实基础。 温馨提示： 本文所有命令行操作均在 Git Bash 中执行。 请确保您的网络环境已启用科学上网。 环境准备 windows系统 安装jdk1.8并配置好环境变量 安装git 安装idea 项目准备1. git配置 1234567891011# 配置全局用户名称git...