ZGC 垃圾回收过程

ZGC（Z Garbage Collector）是Java平台上的一种垃圾收集器，它是由Oracle开发的，旨在解决大堆的低延迟垃圾收集问题。ZGC是一种并发的分代垃圾收集器，它主要针对具有大内存需求和低停顿时间要求的应用程序

ZGC的核心概念及对应的JVM参数详见 分代ZGC详解

分代ZGC收集器具备以下特性：

  • 没有多重映射内存
  • 内存屏障优化
  • 双重缓冲记忆集
  • 无需额外堆内存重分配
  • 堆区域密度
  • 大对象处理

ZGC 垃圾回收过程

ZGC使用了一种称为并发压缩的技术，在垃圾回收过程中进行垃圾对象的压缩和内存整理。下面是ZGC垃圾回收的大致过程：

  1. 初始标记：ZGC会标记出所有的根对象，包括线程栈上的引用、静态变量和一些特殊的对象。初始标记的目的是确定一组初始的存活对象，以便在后续的并发标记和重定位阶段中进行处理
  2. 并发标记/对象重定位：并发地遍历堆中的对象，并标记出这些对象的存活状态。同时，ZGC会将存活对象从旧的内存区域重定位到新的内存区域，以便为后续的对象分配提供更大的连续空间。这个阶段的并发执行可以减少垃圾回收对应用程序的停顿时间
  3. 再标记：在并发标记阶段期间，应用程序可能会继续产生新的对象，而这些新对象也需要被标记为存活。因此，ZGC需要进行一次再标记阶段，以标记并更新在并发标记期间产生的新对象
  4. 并发转移准备：在并发转移准备阶段，ZGC会准备进行并发的对象转移。这包括处理与并发标记阶段重叠的一些操作，例如更新引用和处理根对象。这个阶段的目的是为并发转移阶段做准备，以确保在该阶段的并发执行期间，应用程序的执行不会受到过多的停顿。
  5. 初始转移：ZGC会将剩余的存活对象从旧的内存区域转移到新的内存区域。
  6. 并发转移：ZGC会在后台并发地处理剩余的存活对象，并将它们从旧的内存区域转移到新的内存区域。与并发标记/对象重定位阶段一样，这个阶段的并发执行可以最大程度地减少应用程序的停顿时间

在ZGC的整个垃圾回收过程中，大部分工作都是与应用程序线程并发执行的，因此ZGC的主要特点是低延迟和高吞吐量，适合对响应时间有较高要求的应用场景

ZGC只有三个STW阶段：初始标记，再标记，初始转移。 其中，初始标记和初始转移分别都只需要扫描所有GC Roots，其处理时间和GC Roots的数量成正比，一般情况耗时非常短；再标记阶段STW时间很短，最多1ms，超过1ms则再次进入并发标记阶段。即，ZGC几乎所有暂停都只依赖于GC Roots集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加

ZGC 日志分析

GC(4125) Heap before GC invocations=4125 (full 4125):
GC(4125)  ZHeap           used 1942M, capacity 4536M, max capacity 4536M
GC(4125)  Metaspace       used 146734K, committed 148096K, reserved 344064K
GC(4125)   class space    used 17468K, committed 18240K, reserved 212992K
GC(4125) Garbage Collection (Proactive)
GC(4125) Using 1 workers
GC(4125) Pause Mark Start 0.041ms
Safepoint "XMarkStart", Time since last: 22124432085 ns, Reaching safepoint: 17382 ns, Cleanup: 6329 ns, At safepoint: 76852 ns, Total: 100563 ns
GC(4125) Concurrent Mark 322.101ms
GC(4125) Pause Mark End 0.022ms
Safepoint "XMarkEnd", Time since last: 322171078 ns, Reaching safepoint: 9147 ns, Cleanup: 8722 ns, At safepoint: 52553 ns, Total: 70422 ns
GC(4125) Concurrent Mark Free 0.001ms
GC(4125) Concurrent Process Non-Strong References 41.260ms
GC(4125) Concurrent Reset Relocation Set 0.125ms
Safepoint "CleanClassLoaderDataMetaspaces", Time since last: 41168753 ns, Reaching safepoint: 76926 ns, Cleanup: 6011 ns, At safepoint: 3152494 ns, Total: 3235431 ns
GC(4125) Concurrent Select Relocation Set 5.057ms
GC(4125) Pause Relocate Start 0.019ms
Safepoint "XRelocateStart", Time since last: 2142288 ns, Reaching safepoint: 16014 ns, Cleanup: 4139 ns, At safepoint: 60372 ns, Total: 80525 ns
GC(4125) Concurrent Relocate 41.819ms
GC(4125) Heap after GC invocations=4126 (full 4126):
GC(4125)  ZHeap           used 242M, capacity 4536M, max capacity 4536M
GC(4125)  Metaspace       used 146734K, committed 148096K, reserved 344064K
GC(4125)   class space    used 17468K, committed 18240K, reserved 212992K
GC(4125) Load: 7.70/8.06/8.36
GC(4125) MMU: 2ms/85.9%, 5ms/94.4%, 10ms/97.2%, 20ms/98.6%, 50ms/99.4%, 100ms/99.7%
GC(4125) Mark: 1 stripe(s), 2 proactive flush(es), 1 terminate flush(es), 0 completion(s), 0 continuation(s) 
GC(4125) Mark Stack Usage: 32M
GC(4125) NMethods: 11693 registered, 10397 unregistered
GC(4125) Metaspace: 143M used, 144M committed, 336M reserved
GC(4125) Soft: 3566 encountered, 954 discovered, 0 enqueued
GC(4125) Weak: 21037 encountered, 7964 discovered, 6855 enqueued
GC(4125) Final: 45 encountered, 8 discovered, 0 enqueued
GC(4125) Phantom: 757 encountered, 499 discovered, 10 enqueued
GC(4125) Small Pages: 924 / 1848M, Empty: 8M, Relocated: 26M, In-Place: 0
GC(4125) Medium Pages: 2 / 64M, Empty: 32M, Relocated: 0M, In-Place: 0
GC(4125) Large Pages: 5 / 30M, Empty: 0M, Relocated: 0M, In-Place: 0
GC(4125) Forwarding Usage: 10M
GC(4125) Min Capacity: 4536M(100%)
GC(4125) Max Capacity: 4536M(100%)
GC(4125) Soft Max Capacity: 4536M(100%)
GC(4125)                Mark Start          Mark End        Relocate Start      Relocate End           High               Low         
GC(4125)  Capacity:     4536M (100%)       4536M (100%)       4536M (100%)       4536M (100%)       4536M (100%)       4536M (100%)   
GC(4125)      Free:     2594M (57%)        2564M (57%)        2600M (57%)        4294M (95%)        4294M (95%)        2560M (56%)    
GC(4125)      Used:     1942M (43%)        1972M (43%)        1936M (43%)         242M (5%)         1976M (44%)         242M (5%)     
GC(4125)      Live:         -               157M (3%)          157M (3%)          157M (3%)             -                  -          
GC(4125) Allocated:         -                30M (1%)           34M (1%)           38M (1%)             -                  -          
GC(4125)   Garbage:         -              1784M (39%)        1744M (38%)          45M (1%)             -                  -          
GC(4125) Reclaimed:         -                  -                40M (1%)         1738M (38%)            -                  -          
GC(4125) Garbage Collection (Proactive) 1942M(43%)->242M(5%)

关键点中文解释

  • GC(4125) HEAP BEFORE GC invocations=4125 (FULL 4125): 执行垃圾回收前的引用数
  • GC(4125) Garbage Collection (Proactive): 执行的是一次主动的垃圾回收。
  • GC(4125) USING 1 workers: 使用了1个工作线程。
  • GC(4125) CONCURRENT Mark 322.101ms: 并发标记阶段的耗时
  • GC(4125) CONCURRENT PROCESS Non-Strong REFERENCES 41.260ms: 并发处理非强引用的耗时
  • GC(4125) CONCURRENT RESET Relocation SET 0.125ms: 再标记阶段的耗时
  • GC(4125) CONCURRENT SELECT Relocation SET 5.057ms: 并发选择回收区域的耗时
  • GC(4125) CONCURRENT Relocate 41.819ms: 并发转移阶段的耗时
  • GC(4125) HEAP AFTER GC invocations=4126 (FULL 4126): 执行垃圾回收后的引用数

ZGC 垃圾收集统计

Last 10sLast 10mLast 10hTotal单位
Avg / MaxAvg / MaxAvg / MaxAvg / Max
Collector: Garbage Collection Cycle411.071 / 411.071426.927 / 571.956395.057 / 615.642396.554 / 794.838ms
Contention: Mark Segment Reset Contention0 / 00 / 00 / 00 / 0ops/s
Contention: Mark SeqNum Reset Contention0 / 00 / 00 / 00 / 0ops/s
Critical: Allocation Stall0 / 00 / 00 / 00 / 0ops/s
Critical: Allocation Stall0.000 / 0.0000.000 / 0.0000.000 / 0.0000.000 / 0.000ms
Critical: GC Locker Stall0 / 00 / 00 / 10 / 1ops/s
Critical: GC Locker Stall0.000 / 0.0000.000 / 0.0000.182 / 1.0800.135 / 1.156ms
Critical: Relocation Stall0 / 00 / 00 / 00 / 0ops/s
Critical: Relocation Stall0.000 / 0.0000.000 / 0.0000.000 / 0.0000.000 / 0.000ms
Memory: Allocation Rate83 / 14074 / 14851 / 21852 / 368MB/s
Memory: Defragment0 / 00 / 00 / 00 / 0ops/s
Memory: Out Of Memory0 / 00 / 00 / 00 / 0ops/s
Memory: Page Cache Flush0 / 00 / 00 / 00 / 0MB/s
Memory: Page Cache Hit L141 / 5937 / 6725 / 10926 / 184ops/s
Memory: Page Cache Hit L20 / 00 / 00 / 00 / 0ops/s
Memory: Page Cache Hit L30 / 00 / 00 / 00 / 63ops/s
Memory: Page Cache Miss0 / 00 / 00 / 00 / 1ops/s
Memory: Uncommit0 / 00 / 00 / 00 / 0MB/s
Memory: Undo Object Allocation Failed6 / 634 / 4471 / 6551 / 1196ops/s
Memory: Undo Object Allocation Succeeded21 / 2105 / 4822 / 6052 / 751ops/s
Memory: Undo Page Allocation0 / 30 / 30 / 50 / 7ops/s
Phase: Concurrent Mark322.101 / 322.101336.304 / 443.879317.178 / 518.134316.142 / 596.839ms
Phase: Concurrent Mark Continue0.000 / 0.0000.000 / 0.0000.000 / 0.0000.000 / 0.000ms
Phase: Concurrent Mark Free0.001 / 0.0010.001 / 0.0010.001 / 0.0310.001 / 0.031ms
Phase: Concurrent Process Non-Strong References41.260 / 41.26039.545 / 74.00236.013 / 74.00237.811 / 128.820ms
Phase: Concurrent Relocate41.819 / 41.81944.695 / 54.79935.851 / 61.68036.447 / 154.466ms
Phase: Concurrent Reset Relocation Set0.125 / 0.1250.130 / 0.1820.082 / 0.2870.096 / 0.539ms
Phase: Concurrent Select Relocation Set5.057 / 5.0575.580 / 6.7145.248 / 9.5775.375 / 96.450ms
Phase: Pause Mark End0.022 / 0.0220.027 / 0.0610.024 / 0.0770.024 / 0.103ms
Phase: Pause Mark Start0.041 / 0.0410.035 / 0.0490.036 / 0.2810.035 / 0.281ms
Phase: Pause Relocate Start0.019 / 0.0190.021 / 0.0300.020 / 0.0760.020 / 0.096ms
Subphase: Concurrent Classes Purge0.008 / 0.0080.031 / 0.2030.018 / 1.8350.072 / 67.248ms
Subphase: Concurrent Classes Unlink34.205 / 34.20532.226 / 65.28829.823 / 65.28831.479 / 89.630ms
Subphase: Concurrent Mark316.043 / 316.043330.668 / 437.551311.415 / 512.480310.233 / 588.118ms
Subphase: Concurrent Mark Try Flush0.120 / 0.2470.113 / 0.2490.114 / 3.1570.116 / 8.934ms
Subphase: Concurrent Mark Try Terminate0.028 / 0.0550.029 / 0.0760.031 / 0.4330.031 / 0.657ms
Subphase: Concurrent References Enqueue0.006 / 0.0060.006 / 0.0100.005 / 0.0450.006 / 0.064ms
Subphase: Concurrent References Process2.721 / 2.7212.955 / 4.3411.961 / 5.2112.033 / 37.505ms
Subphase: Concurrent Roots ClassLoaderDataGraph0.697 / 0.6970.626 / 0.7780.619 / 1.5920.635 / 1.764ms
Subphase: Concurrent Roots CodeCache0.000 / 0.0000.000 / 0.0000.000 / 0.0000.000 / 0.000ms
Subphase: Concurrent Roots JavaThreads5.053 / 5.0534.708 / 5.1804.889 / 91.0785.013 / 91.078ms
Subphase: Concurrent Roots OopStorageSet0.162 / 0.1620.138 / 0.1620.141 / 1.0290.144 / 1.029ms
Subphase: Concurrent Weak Roots OopStorageSet3.957 / 3.9573.962 / 4.5893.840 / 6.3333.849 / 8.860ms
Subphase: Pause Mark Try Complete0.000 / 0.0000.016 / 0.0160.011 / 0.0260.010 / 0.027ms
System: Java Threads87 / 8787 / 8987 / 9186 / 112thread

G1/ZGC 回收过程对比

G1垃圾回收周期

G1的混合回收过程可以分为标记阶段、清理阶段和复制阶段。

标记阶段停顿分析

  • 初始标记阶段：初始标记阶段是指从GC Roots出发标记全部直接子节点的过程，该阶段是STW的。由于GC Roots数量不多，通常该阶段耗时非常短。

  • 并发标记阶段：并发标记阶段是指从GC Roots开始对堆中对象进行可达性分析，找出存活对象。该阶段是并发的，即应用线程和GC线程可以同时活动。并发标记耗时相对长很多，但因为不是STW，所以我们不太关心该阶段耗时的长短。

  • 再标记阶段：重新标记那些在并发标记阶段发生变化的对象。该阶段是STW的。
    清理阶段停顿分析

  • 清理阶段：清点出有存活对象的分区和没有存活对象的分区，该阶段不会清理垃圾对象，也不会执行存活对象的复制。该阶段是STW的。

复制阶段停顿分析

  • 复制算法中的转移阶段需要分配新内存和复制对象的成员变量。转移阶段是STW的，其中内存分配通常耗时非常短，但对象成员变量的复制耗时有可能较长，这是因为复制耗时与存活对象数量与对象复杂度成正比。对象越复杂，复制耗时越长

四个STW过程中，初始标记因为只标记GC Roots，耗时较短。再标记因为对象数少，耗时也较短。清理阶段因为内存分区数量少，耗时也较短。转移阶段要处理所有存活的对象，耗时会较长。因此，G1停顿时间的瓶颈主要是标记-复制中的转移阶段STW

ZGC只有三个STW阶段：初始标记，再标记，初始转移。ZGC几乎所有暂停都只依赖于GC Roots集合大小，停顿时间不会随着堆的大小或者活跃对象的大小而增加

与ZGC对比，G1的转移阶段完全STW的，且停顿时间随存活对象的大小增加而增加

参考资料：

  1. 分代ZGC详解
  2. 新一代垃圾回收器ZGC的探索与实践
  3. 分代ZGC
  4. G1 垃圾收集器详解

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/190647.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

大数据平台/大数据技术与原理-实验报告--部署全分布模式Hadoop集群

大数据平台/大数据技术与原理-实验报告--部署全分布模式Hadoop集群

实验名称 部署全分布模式Hadoop集群 实验性质 （必修、选修） 必修 实验类型（验证、设计、创新、综合） 综合 实验课时 2 实验日期 2023.10.16-2023.10.20 实验仪器设备以及实验软硬件要求 专业实验室（配有cen…
阅读更多...
【Android Gradle】之Gradle入门及 wrapper 生成（一）

【Android Gradle】之Gradle入门及 wrapper 生成（一）

😄作者简介： 小曾同学.com,一个致力于测试开发的博主⛽️，主要职责：测试开发、CI/CD 如果文章知识点有错误的地方，还请大家指正，让我们一起学习，一起进步。 😊 座右铭：不…
阅读更多...
Stm32CubeMx生成代码提示缺少“core_cm3.h“

Stm32CubeMx生成代码提示缺少“core_cm3.h“

Stm32CubeMx生成代码提示缺少"core_cm3.h" 1.原因分析 1.1问题根源 在我们使用本地解压的方法去安装固件包,但是找错了要下载的固件包😊.在你点击进入下载页面之后,能看到一共有两个下载链接,其中上面的是补丁包,而第二个才是我们应该要下载的固件包 当…
阅读更多...
3DCAT为华东师大设计学院打造元宇宙数字虚拟学院

3DCAT为华东师大设计学院打造元宇宙数字虚拟学院

6月11日，华东师范大学设计学院在chi K11美术馆举办了一场别开生面的 2023 年本科毕业设计暨项目实践教学现场演示展。其中，元宇宙数字虚拟学院（一期）的现场发布会引起了现场震撼，吸引了众多观众的目光和参与。 该元宇宙…
阅读更多...
数据库基础教程之序列自增设置（三）

数据库基础教程之序列自增设置（三）

点击public来选择一个模式。 选择其他-》序列。 选择新建序列。 设置序列参数（最大值不超过2的63次方-1）。 点击保存。 刷新序列列表，可以看见新建序列。 设置主键自增 打开设计表-》选中字段-》默认值设置为：nextval(‘log_text’…
阅读更多...
如何在Ubuntu系统上安装MongoDB

如何在Ubuntu系统上安装MongoDB

简单介绍 MongoDB是由C语言编写的，是一个基于分布式文件存储的开源数据库系统。在高负载的情况下，添加更多的节点，可以保证服务器性能。MongoDB旨在为WEB应用提供可扩展的高性能数据存储解决方案。MongoDB将数据存储为一个文档，数…
阅读更多...
GCPS—20型工程钻机的设计自动摊铺机的设计机械设计

GCPS—20型工程钻机的设计自动摊铺机的设计机械设计

wx供重浩：创享日记 对话框发送：摊铺机 获取完整论文报告工程源文件 摊铺机是一种复合式多功能摊铺机，为适应我国深基础和连续墙以及水利、纺织的发展与需要，结合大口径摊铺机灌注桩和地下连续墙施工的特点，为解决在复…
阅读更多...
论文笔记--Toolformer: Language Models Can Teach Themselves to Use Tools

论文笔记--Toolformer: Language Models Can Teach Themselves to Use Tools

论文笔记--Toolformer: Language Models Can Teach Themselves to Use Tools 1. 文章简介2. 文章概括3 文章重点技术3.1 Toolformer3.2 APIs 4. 文章亮点5. 原文传送门 1. 文章简介 标题：Toolformer: Language Models Can Teach Themselves to Use Tools作者&#…
阅读更多...
佳易王商超便利店进销存管理系统软件下载，扫描商品自动计算金额支持扫码支付

佳易王商超便利店进销存管理系统软件下载，扫描商品自动计算金额支持扫码支付

佳易王商超便利店进销存管理系统软件下载，扫描商品自动计算金额支持扫码支付 软件特色： 1、功能实用，操作简单，不会电脑也会操作，软件免安装，已内置数据库。软件在关闭的时候，可以设置会员数据…
阅读更多...
《C++PrimePlus》第10章 对象和类

《C++PrimePlus》第10章 对象和类

10.1 过程性编程和面向对象编程 10.2 抽象和类 10.3 类的构造函数和析构函数 类的定义和使用&#xff08;买卖股票&#xff09; 头文件stock10.h #ifndef __STOCK00__H__ #define __STOCK00__H__#include <string>class Stock { // pravate的内容只能通过public访问 p…
阅读更多...
jsp生成验证码的代码

jsp生成验证码的代码

效果图&#xff1a; loginProcess.jsp <% page language"java" contentType"text/html; charsetUTF-8"pageEncoding"UTF-8"%><% String captcharequest.getParameter("captcha");%><% String captcha_session(String)s…
阅读更多...
新手如何购买保险，保险投资基础入门

新手如何购买保险，保险投资基础入门

一、教程描述 本套保险教程&#xff0c;大小2.63G&#xff0c;共有11个文件。 二、教程目录 第01课 保险到底有什么用.mp4 第02课 已有社保还需要商业保险吗.mp4 第03课 你必须要懂的保险基础知识.mp4 第04课 关于重疾你必须要知道的几件事情.mp4 第05课 家庭重疾险如何…
阅读更多...
Python 安装mysqlclient 错误 无法打开包括文件: “mysql.h”: 解决方法

Python 安装mysqlclient 错误 无法打开包括文件: “mysql.h”: 解决方法

解决方案&#xff1a;python最新3.12.0不支持mysqlclient 请下载 python3.9.9 版本 高速下载地址CNPM Binaries Mirror 官方下载地址Welcome to Python.org 下载完成后将python添加到环境变量 pycharm 虚拟环境下的python版本切换到你刚才下载的3.9.9的python版本 Avai…
阅读更多...
SpringBoot事务处理

SpringBoot事务处理

一、事务回顾 回顾地址&#xff1a; 深入理解数据库事务&#xff08;超详细&#xff09;_数据库事务操作_Maiko Star的博客-CSDN博客 事务&#xff1a; 是一组操作的集合&#xff0c;是一个不可分割的工作单位&#xff0c;这些操作要么同时成功&#xff0c;要么同时失败 事…
阅读更多...
【数据分享】我国12.5米分辨率的坡向数据（免费获取）

【数据分享】我国12.5米分辨率的坡向数据（免费获取）

地形数据&#xff0c;也叫DEM数据&#xff0c;是我们在各项研究中最常使用的数据之一。之前我们分享过源于NASA地球科学数据网站发布的12.5米分辨率DEM地形数据&#xff01;基于该数据我们处理得到12.5米分辨率的坡度数据、12.5米分辨率的山体阴影数据&#xff08;均可查看之前…
阅读更多...
MySQL 8 手动安装后无法启动的问题解决

MySQL 8 手动安装后无法启动的问题解决

开头还是介绍一下群&#xff0c;如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题&#xff0c;有需求都可以加群群内有各大数据库行业大咖&#xff0c;CTO&#xff0c;可以解决你的问题。加群请联系 liuaustin3 &#xff0c;&#xff08;…
阅读更多...
LeetCode：1457. 二叉树中的伪回文路径（DFS C++ Java）

LeetCode：1457. 二叉树中的伪回文路径（DFS C++ Java）

目录 1457. 二叉树中的伪回文路径 题目描述&#xff1a; 原理思路&#xff1a; 1457. 二叉树中的伪回文路径 题目描述&#xff1a; 给你一棵二叉树&#xff0c;每个节点的值为 1 到 9 。我们称二叉树中的一条路径是 「伪回文」的&#xff0c;当它满足&#xff1a;路径经过的…
阅读更多...
基于单片机DHT11湿度测量与控制-CO2-光照报警系统程序和仿真

基于单片机DHT11湿度测量与控制-CO2-光照报警系统程序和仿真

一、系统方案 1、本设计采用这51单片机作为主控器。 2、DHT11温湿度、CO2、光照强度送到液晶1602显示。 3、按键设置报警值。 4、蜂鸣器报警。 二、硬件设计 原理图如下&#xff1a; 三、单片机软件设计 1、首先是系统初始化 //初始化LCD*********************************…
阅读更多...
初始化GPIO流程 以及点亮LED

初始化GPIO流程 以及点亮LED

点亮LED 需要单片机上的GIPIO端口引脚 输出对应的电压来对LED进行点亮 &#xff0c;关于GPIO的初始化流程其实我们只需要牢牢记住这张图即可 具体参考&#xff1a; https://blog.csdn.net/k666499436/article/details/123971479 1. GPIO的初始化 流程 使能时钟 在stm32中&…
阅读更多...
51单片机蜂鸣器发出悦耳的声音

51单片机蜂鸣器发出悦耳的声音

51单片机蜂鸣器发出悦耳的声音 1.概述 这篇文章介绍单片机控制蜂鸣器入门小实验&#xff0c;通过该实验掌握蜂鸣器发声的原理&#xff0c;控制声音发出我们想听的音乐。 2.蜂鸣器发声 2.1.硬件原理 1.蜂鸣器正极接单片机20号引脚VCC&#xff0c;负极接19号引脚P1.7 2.20MH…
阅读更多...
最新文章

Copyright @ 2022~2023