【零基础学java】(等待唤醒机制,线程池补充)

【零基础学java】(等待唤醒机制,线程池补充)

等待唤醒机制

生产者和消费者(常见方法)
void wait()当前线程等待,直到被其他线程唤醒
void notify()随机唤醒单个线程
void notifyAll()唤醒所有线程

等待唤醒机制的阻塞队列方式实现

put数据时:放不进去会等着,叫做阻塞

take数据时:取出第一个,取不到的等着

线程的六种状态

线程池

线程池的作用

 1减少线程创建和销毁的开销

  • 问题:每次需要任务时都创建新线程,完成后立即销毁,会消耗大量CPU和内存资源。
  • 解决:线程池复用已创建的线程,避免频繁创建/销毁。

2. 控制并发.数量,防止系统过载

  • 问题:无限制创建线程可能导致:
    • 内存耗尽
    • CPU过度切换(上下文切换开销大)
    • 系统不稳定
  • 解决:线程池设置最大线程数,控制同时运行的线程数量。

3. 提高响应速度

  • 任务到达时,通常已有空闲线程可以立即执行,无需等待线程创建。

4. 统一管理线程生命周期

  • 提供统一的调度、监控和资源回收机制。

二、核心作用

1. 资源复用

  • 线程作为系统稀缺资源,重复使用已创建线程。
  • 类似数据库连接池,避免频繁申请释放。

2. 流量控制(削峰填谷)

  • 当突发大量请求时,线程池通过队列缓冲:
    • 核心线程 → 队列 → 非核心线程(按配置策略)
  • 避免瞬时高峰压垮系统。

3. 提供灵活的任务调度策略

  • 支持多种队列(有界/无界、优先级队列)。
  • 支持拒绝策略(当队列满且线程达上限时的处理方式)。

4. 提高系统可管理性

  • 可监控线程状态、活动线程数、完成任务数等。
  • 便于调优和问题诊断。

运行过程

线程池的参数

创建线程池的对象

任务拒绝策略

线程池主要核心原理


①创建一个池子,池子中是空的
②提交任务时,池子会创建新的线程对象,任务执行完毕,线程归还给池子
下回再次提交任务时,不需要创建新的线程,直接复用已有的线程即可

但是如果提交任务时,池子中没有空闲线程,也无法创建新的线程,任务就会排队等待

线程池的大小

线程池的缺点

  • 配置复杂(参数需要根据场景调优)
  • 不当配置可能导致:
    • 队列堆积 → 内存溢出
    • 线程数不足 → 响应慢
    • 线程数过多 → CPU过度切换

Read more

Flutter 组件 yaml_codec 适配鸿蒙 HarmonyOS 实战:高性能 YAML 编解码,构建标准化配置治理与动态资产解析架构

Flutter 组件 yaml_codec 适配鸿蒙 HarmonyOS 实战:高性能 YAML 编解码,构建标准化配置治理与动态资产解析架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 yaml_codec 适配鸿蒙 HarmonyOS 实战:高性能 YAML 编解码,构建标准化配置治理与动态资产解析架构 前言 在鸿蒙(OpenHarmony)生态迈向工业级应用、涉及复杂环境参数配置、多端差异化资源映射及高性能静态资产(Assets)加载的背景下,如何实现一种既具备人类可读性又具备机器高效解析能力的“配置语言”治理,已成为决定应用灵活性与工程可维护性的关键。在鸿蒙设备这类强调分布式部署且配置项密集的环境下,如果应用依然依赖臃肿的 JSON 或自定义的 Key-Value 格式,由于由于嵌套层次的复杂性与缺乏注释支持,极易由于由于“配置语义模糊”导致跨团队协作时的误操作。 我们需要一种能够支持层级嵌套、具备强类型映射且符合 YAML 1.2 标准的高性能编解码方案。 yaml_codec 为 Flutter 开发者引入了结构化的 YAML

By Ne0inhk
RUST:异步代码的测试与调试艺术

RUST:异步代码的测试与调试艺术

RUST:异步代码的测试与调试艺术 一、异步测试的本质与难点 1.1 异步测试与同步测试的区别 💡在Rust同步编程中,测试通常是顺序执行的,每个测试函数会阻塞线程直到完成,结果是确定的。而异步测试的结果可能受到任务调度、网络延迟、数据库连接等因素的影响,时序性和状态管理更加复杂。 同步测试示例: #[cfg(test)]modtests{#[test]fntest_add(){assert_eq!(1+1,2);}} 异步测试示例(使用Tokio测试宏): #[cfg(test)]modtests{usetokio::time::sleep;usestd::time::Duration;#[tokio::test]asyncfntest_async_add(){sleep(Duration::from_millis(100)).await;assert_

By Ne0inhk
Flutter 组件 activity_files 适配鸿蒙 HarmonyOS 实战:文件活动流治理,构建高性能存储沙箱访问与资产全生命周期管理架构

Flutter 组件 activity_files 适配鸿蒙 HarmonyOS 实战:文件活动流治理,构建高性能存储沙箱访问与资产全生命周期管理架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 activity_files 适配鸿蒙 HarmonyOS 实战:文件活动流治理,构建高性能存储沙箱访问与资产全生命周期管理架构 前言 在鸿蒙(OpenHarmony)生态迈向全场景分布式协同、涉及海量多媒体资产处理及严苛应用沙箱(Sandbox)隔离的背景下,如何实现一套既能穿透复杂的层级目录、又能实时追踪文件变更活动且具备极高 I/O 吞吐能力的存储治理架构,已成为决定应用性能广度与数据安全深度。在鸿蒙设备这类强调 AOT 极致性能与受限文件权限周期的环境下,如果应用依然采用陈旧的同步文件读取或缺乏活动追踪的直接 I/O,由于由于频繁的磁盘竞争,极易由于由于“主线程阻塞”或“资产状态不同步”导致用户在管理大型媒体库时发生明显的感知性卡顿。 我们需要一种能够解耦文件路径、支持异步流式追踪(Activity Tracking)且符合鸿蒙分布式文件系统安全范式的操作框架。 activity_files 为 Flutter 开发者引入了“

By Ne0inhk