JVM的GC详解

获取GC日志方式大抵有两种

第一种就是设定JVM参数在程序启动时查看，具体的命令参数为:

-XX:+PrintGCDetails # 打印GC日志
-XX:+PrintGCTimeStamps # 打印每一次触发GC时发生的时间

第二种则是在服务器上监控:使用jstat查看,如下所示，命令格式为jstat -gc pid 输出间隔时长 输出次数，例如笔者希望每隔1秒输出1次，并且打印5次，对应的指令如下：

jstat -gc 21608 1000 5

public static void main(String[] args) {//分配1M内存空间byte[] bytes = new byte[1024 * 1024];//触发minor gc，剩余512k，然后将1M空间存放至新生代，堆空间大约剩下1.5Mbytes = new byte[1024 * 1024];//分配至新生代约2.5Mbytes = new byte[1024 * 1024];//新生代空间不足，触发full gc，新生代空间全回收，并执行CMS GC，完成后将对象存放至新生代byte[] byte2 = new byte[2 * 1024 * 1024];}

设置JVM配置参数指明新生代、老年代堆空间大小为5M，并指明新生代Eden和survivor区的比例为8:1:1，同时我们也指定的新生代和老年代垃圾回收算法分别是ParNewGC和CMS：

-XX:NewSize=5M -XX:MaxNewSize=5M -XX:InitialHeapSize=10M -XX:MaxHeapSize=10M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
  • -XX:NewSize=5M：设置新生代的初始大小为 5MB。
  • -XX:MaxNewSize=5M：设置新生代的最大大小为 5MB。
  • -XX:InitialHeapSize=10M：设置 JVM 堆的初始大小为 10MB。
  • -XX:MaxHeapSize=10M：设置 JVM 堆的最大大小为 10MB。
  • -XX:SurvivorRatio=8：设置 Eden 区与 Survivor 区的比例为 8，即 Eden 占用 8/10 的新生代空间，两个 Survivor 各占 1/10。
  • -XX:PretenureSizeThreshold=10M：设置对象直接进入老年代的阈值为 10MB，超过这个大小的对象会直接分配到老年代。
  • -XX:+UseParNewGC：启用并行新生成收集器（Parallel New Generation Collector），用于多线程环境下的新生代垃圾回收。
  • -XX:+UseConcMarkSweepGC：启用并发标记清除收集器（Concurrent Mark Sweep Collector），用于多线程环境下的老年代垃圾回收。
  • -XX:+PrintGCDetails：打印详细的垃圾回收日志信息。
  • -XX:+PrintGCTimeStamps：在垃圾回收日志中添加时间戳。

GC过程：

  1. 首先代码执行到byte[] bytes = new byte[1024 * 1024];，此时新生代空间充裕，没有任何输出。

  2. 执行第二行代码bytes = new byte[1024 * 1024];再次进程内存分配时，发现新生代空间不足出现以此minor gc，对应输出结果如下，

    2.938: [GC (Allocation Failure) 2.938: [ParNew: 3348K->512K(4608K), 0.0016244 secs] 3348K->1692K(9728K), 0.0016904 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

    我们大体可以看出GC原因是Allocation Failure即新生代不能分配对象，触发一次新生代GC，新生代GC前后空间由3348K变为512K，整堆空间由3348K变为1692K，最后输出了GC耗时、系统响应耗时以及应用程序暂停时间

完成上述GC，将1M的数组存放至新生代，此时新生代的堆空间大约是1M：
在这里插入图片描述

  1. 然后第三行再次分配数组，新生代空间充裕，直接存入：
    在这里插入图片描述

  2. 最后一次分配2M数组时，新生代空间不足且空间分配担保失败，直接触发FULL GC，从日志中我们可以看到minor gc直接将上述的所有字节数组都回收了：

    9.689: [GC (Allocation Failure) 9.689: [ParNew: 2626K->0K(4608K), 0.0021520 secs] 3806K->2746K(9728K), 0.0021903 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

  3. 最后就是CMS老年代GC，首先进行初始标记阶段该阶段为STW并找到所有的GC root，从日志中我们看到老年代使用的容量为2718K且总容量为5120K，后面的4766K(9728K)标记为当前堆的实际大小和总容量：

    2.057: [GC (CMS Initial Mark) [1 CMS-initial-mark: 2718K(5120K)] 4766K(9728K), 0.0005690 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

  4. 然后进入并发标记阶段该阶段不会STW，先是CMS-concurrent-mark标记gc root可达对象，然后CMS-concurrent-preclean重新并发扫描进入到老年代的对象，最后时CMS-concurrent-abortable-preclean该阶段并发运行至eden区空间占用率达到满意：

    2.058: [CMS-concurrent-mark-start]
2.059: [CMS-concurrent-mark: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2.059: [CMS-concurrent-preclean-start]
2.059: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2.059: [CMS-concurrent-abortable-preclean-start]CMS: abort preclean due to time 7.163: [CMS-concurrent-abortable-preclean: 0.005/5.105 secs] [Times: user=0.00 sys=0.00, real=5.10 secs]

  5. 最后就到了最终标记阶段，该阶段会STW，从日志输出可以看出新生代占用2048k，当前这个重新标记阶段Rescan 花费了0.0004620 secs，其余就是处理弱引用、卸载无用的类以及清理元数据等花费时间和耗时：

    7.164: [GC (CMS Final Remark) [YG occupancy: 2048 K (4608 K)]7.164: [Rescan (parallel) , 0.0004620 secs]7.164: [weak refs processing, 0.0001727 secs]7.164: [class unloading, 0.0005772 secs]7.165: [scrub symbol table, 0.0011975 secs]7.166: [scrub string table, 0.0003404 secs][1 CMS-remark: 2718K(5120K)] 4766K(9728K), 0.0030256 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

  6. 最后就是并发的清理垃圾会重置标记，等待下一个周期的GC：

    7.167: [CMS-concurrent-sweep-start]
7.168: [CMS-concurrent-sweep: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
7.168: [CMS-concurrent-reset-start]
7.168: [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

  7. 最后我们查看内存使用情况可以看到，新生代的2M就是我们最后分配的数组，在eden区，而老年代使用了1677K：

    Heappar new generation   total 4608K, used 2089K [0x00000000ff600000, 0x00000000ffb00000, 0x00000000ffb00000)eden space 4096K,  51% used [0x00000000ff600000, 0x00000000ff80a558, 0x00000000ffa00000)from space 512K,   0% used [0x00000000ffa00000, 0x00000000ffa00000, 0x00000000ffa80000)to   space 512K,   0% used [0x00000000ffa80000, 0x00000000ffa80000, 0x00000000ffb00000)concurrent mark-sweep generation total 5120K, used 1677K [0x00000000ffb00000, 0x0000000100000000, 0x0000000100000000)Metaspace       used 3124K, capacity 4486K, committed 4864K, reserved 1056768Kclass space    used 327K, capacity 386K, committed 512K, reserved 1048576K

频繁的gc

  • Minor GC:发生在年轻代的空间回收，包含eden和survivor，也叫做Young GC。
  • Major GC:在老年代堆区进行空间回收。
  • Full GC:清理所有堆区的内存空间的垃圾内存，包括年轻代和老年代。

频繁的 minor gc 和major gc

public static void main(String[] args) throws Exception {while (true) {//分配3M数组byte[] bytes = new byte[1024 * 1024];bytes = new byte[1024 * 1024];bytes = new byte[1024 * 1024];//创建2M的新对象触发GCbyte[] byte2 = new byte[2 * 1024 * 1024];Thread.sleep(1000);}}

设置该程序的堆内存新生代为5M，按照8:1:1的比例分配，这也就意为着Eden区内存大小为4M，然后S区分别是512K，这也就意味着在待分配对象加Eden区堆空间超过4M就会触发minor gc：
在这里插入图片描述
为了演示年轻代的回收行为，我们需要在对这个应用程序的年轻代堆内存改为5M，且Eden区和S区的比例为8:1:1，同时也打印GC日志信息：

-XX:NewSize=5M -XX:MaxNewSize=5M -XX:InitialHeapSize=10M -XX:MaxHeapSize=10M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

输出结果如下，GC日志显示每秒基本都会触发一次Minor GC，进而间接导致频繁的major gc:

在这里插入图片描述
结合配置可知，我们频繁分配对象导致新生代进行频繁的GC，又因为S区大小无法容纳存活的对象，进而使得这些对象提前进入老年代，导致major GC也随之频繁，所以 解决 的办法也比较简单，按照等比例调整大堆空间，即将新生代堆空间调整至10M，保证S区各有2M空间以容纳新生代存活的对象：

-XX:NewSize=10M -XX:MaxNewSize=10M -XX:InitialHeapSize=100M -XX:MaxHeapSize=100M -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

可以看到经过调整之后，基本上Minor gc就能解决问题：
在这里插入图片描述

将年轻代空间调大，是否会更加耗时？
答案是不会的，原因如以：

  • JVM操作本质上都是内存操作，相对而言不会太慢。
  • 将一次GC的时间拆分为t1和t2，t1是扫描年轻代空间是否有垃圾的时间，这个时间的几乎可以忽略不计。而t2则是将eden空间存活的对象复制到survivor区的时间，这个复制操作则是t1时间的10倍。
  • 由此可以看出，避免耗时的正确做法是合理评估新生代堆空间，减少非必要的复制操作，所以说调整新生代的空间并不会导致进一步的耗时问题。

频繁的FULL GC

模拟一个场景，我们的应用中有一个定时任务，这个定时任务每隔1s会想另一个定时任务线程池中提交100个任务，每个任务都会针对Obj 对象进行方法调用：

@Component
public class Task {private static Logger logger = LoggerFactory.getLogger(Task.class);private static final ScheduledThreadPoolExecutor executor =new ScheduledThreadPoolExecutor(50,new ThreadPoolExecutor.DiscardOldestPolicy());private static class Obj {private String name = "name";private int age = 18;private String gender = "man";private LocalDate birthday = LocalDate.MAX;public void func() {//这个方法什么也不做}//返回count个Obj对象private static List<Obj> getObjList(int count) {List<Obj> objList = new ArrayList<>(count);for (int i = 0; i != count; ++i) {objList.add(new Obj());}return objList;}}@Scheduled(cron = "0/1 * *  * * ? ")   //每1秒执行一次public void execute() {logger.info("1s一次定时任务");//向线程池提交100个任务Obj.getObjList(100).forEach(i -> executor.scheduleWithFixedDelay(i::func, 2, 3, TimeUnit.SECONDS));}
}

完成后我们设置下面这段JVM参数后，将其启动：

-Xms20M -Xmx20M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

不久后，控制台出现频繁的full gc，如果在生产环境，频繁的full gc导致stw会导致系统吞吐量下降：

1288.133: [Full GC (Allocation Failure) 1288.133: [CMS1288.142: [CMS-concurrent-preclean: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] (concurrent mode failure): 13695K->13695K(13696K), 0.0610050 secs] 19839K->19836K(19840K), [Metaspace: 29026K->29026K(1077248K)], 0.0610521 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 
1288.258: [Full GC (Allocation Failure) 1288.258: [CMS: 13695K->13695K(13696K), 0.0612134 secs] 19839K->19836K(19840K), [Metaspace: 29026K->29026K(1077248K)], 0.0612676 secs] [Times: user=0.06 sys=0.00, real=0.06 secs] 
1288.320: [GC (CMS Initial Mark) [1 CMS-initial-mark: 13695K(13696K)] 19836K(19840K), 0.0041303 secs] [Times: user=0.03 sys=0.00, real=0.00 secs]

排查思路
定位到程序号后，使用jstat -gc pid10000 10观察其gc情况，可以看到每隔10s，就会增加大量的full gc：

S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT
640.0  640.0   0.0   640.0   5504.0   665.5    13696.0    11176.2   31488.0 28992.6 4352.0 3889.5     39    0.084  15      0.100    0.184
640.0  640.0   0.0   640.0   5504.0   1487.2   13696.0    11176.2   31488.0 28992.6 4352.0 3889.5     39    0.084  25      0.142    0.227
640.0  640.0   0.0   640.0   5504.0   1697.8   13696.0    11176.2   31488.0 28992.6 4352.0 3889.5     39    0.084  35      0.185    0.269

再查看jmap -heap pid查看堆区使用情况，可以看到老年代的使用率还是蛮高的：

Attaching to process ID 26176, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.212-b10using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GCHeap Configuration:MinHeapFreeRatio         = 40MaxHeapFreeRatio         = 70MaxHeapSize              = 20971520 (20.0MB)NewSize                  = 6946816 (6.625MB)MaxNewSize               = 6946816 (6.625MB)OldSize                  = 14024704 (13.375MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 0 (0.0MB)Heap Usage:
New Generation (Eden + 1 Survivor Space):capacity = 6291456 (6.0MB)used     = 5088288 (4.852569580078125MB)free     = 1203168 (1.147430419921875MB)80.87615966796875% used
Eden Space:capacity = 5636096 (5.375MB)used     = 5088288 (4.852569580078125MB)free     = 547808 (0.522430419921875MB)90.28036428052326% used
From Space:capacity = 655360 (0.625MB)used     = 0 (0.0MB)free     = 655360 (0.625MB)0.0% used
To Space:capacity = 655360 (0.625MB)used     = 0 (0.0MB)free     = 655360 (0.625MB)0.0% used
concurrent mark-sweep generation:capacity = 14024704 (13.375MB)used     = 13819664 (13.179458618164062MB)free     = 205040 (0.1955413818359375MB)98.53800836010514% used12064 interned Strings occupying 1120288 bytes.

在排除内存泄漏的问题后，我们通过jmap定位进程中导致是什么对象导致老年代堆区被大量占用：

jmap -histo 7476 | head -n 20

可以看到前20名中的对象都是和定时任务相关，有一个Task$Obj对象非常抢眼，很明显就是因为它的数量过多导致的，此时我们就可以通过定位代码确定如何解决，常见方案无非是: 优化代码、增加空间两种方式，一般来说我们都会采用代码优化的方式去解决。

 num     #instances         #bytes  class name
----------------------------------------------1:         50760        3654720  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask2:         30799        2901552  [C3:         88986        2847552  java.util.concurrent.locks.AbstractQueuedSynchronizer$Node4:         50700        1622400  com.example.jstackTest.Task$Obj5:         50760        1218240  java.util.concurrent.Executors$RunnableAdapter6:         50700         811200  com.example.jstackTest.Task$$Lambda$587/16055533137:          6391         707928  java.lang.Class8:         29256         702144  java.lang.String9:         13577         434464  java.util.concurrent.ConcurrentHashMap$Node10:          6363         341016  [Ljava.lang.Object;11:          1722         312440  [B12:          3414         230424  [I13:             4         210680  [Ljava.util.concurrent.RunnableScheduledFuture;14:          5223         208920  java.util.LinkedHashMap$Entry15:          2297         202136  java.lang.reflect.Method16:          2262         193760  [Ljava.util.HashMap$Node;17:          5668         181376  java.util.HashMap$Node

而本次问题也很明显，任务是一个个提交到定时任务线程池中，是由于定时任务队列DelayedWorkQueue不断堆积任务导致内存被打满。所以最终改成将一个批处理一次性提交到定时任务中立刻将这一批对象回收从而避免耗时任务堆积一堆对象：

 @Scheduled(cron = "0/1 * *  * * ? ")   //每1秒执行一次public void execute() {logger.info("1s一次定时任务");//向线程池提交100个任务executor.scheduleWithFixedDelay(() -> {Obj.getObjList(100).forEach(i -> i.func());}, 2, 3, TimeUnit.SECONDS);}

频繁FULL GC的原因和解决对策

总的来说原因可以频繁FULL GC分为3个:

  1. 用户频繁调用System.gc():这种情况需要修改代码即可，我们不该频繁调用这个方法的。
  2. 老年区空间过小:视情况适当扩大空间。
  3. 大对象过多:这种情况视情况决定是扩大老年代空间或者将大对象拆分。

一般来说，我们优先考虑调整堆内存空间，其次才是针对业务逻辑的代码处理进行更进一步的优化。

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

芯片AI深度实战：给vim装上AI

芯片AI深度实战：给vim装上AI

系列文章&#xff1a; 芯片AI深度实战&#xff1a;私有模型deep seek r1&#xff0c;必会ollama-CSDN博客 芯片AI深度实战&#xff1a;自己的AI&#xff0c;必会LangChain-CSDN博客 芯片AI深度实战&#xff1a;给vim装上AI-CSDN博客 芯片AI深度实战&#xff1a;火的编程AI&…
阅读更多...
供应链系统设计-供应链中台系统设计（十四）- 清结算中心设计篇（三）

供应链系统设计-供应链中台系统设计（十四）- 清结算中心设计篇（三）

关于清结算中心的设计&#xff0c;我们之前的两篇文章中&#xff0c;对于业务诉求的好的标准进行了初步的描述&#xff0c;如果没有看的同学可以参考一下两篇文章进行了解&#xff0c;这样更有利于理解本篇的内容。链接具体如下&#xff1a; 供应链系统设计-供应链中台系统设计…
阅读更多...
搭建自己的专属AI——使用Ollama+AnythingLLM+Python实现DeepSeek本地部署

搭建自己的专属AI——使用Ollama+AnythingLLM+Python实现DeepSeek本地部署

前言 最近DeepSeek模型非常火&#xff0c;其通过对大模型的蒸馏得到的小模型可以较轻松地在个人电脑上运行&#xff0c;这也使得我们有机会在本地构建一个专属于自己的AI&#xff0c;进而把AI“调教”为我们希望的样子。本篇文章中我将介绍如何使用OllamaAnythingLLMPython实现…
阅读更多...
Golang 并发机制-1：Golang并发特性概述

Golang 并发机制-1：Golang并发特性概述

并发是现代软件开发中的一个基本概念&#xff0c;它使程序能够同时执行多个任务&#xff0c;从而提高效率和响应能力。在本文中&#xff0c;我们将探讨并发性在现代软件开发中的重要性&#xff0c;并深入研究Go处理并发任务的独特方法。 并发的重要性 增强性能 并发在提高软…
阅读更多...
【算法应用】基于鲸鱼优化算法求解OTSU多阈值图像分割问题

【算法应用】基于鲸鱼优化算法求解OTSU多阈值图像分割问题

目录 1.鲸鱼优化算法WOA 原理2.OTSU多阈值图像分割模型3.结果展示4.参考文献5.代码获取 1.鲸鱼优化算法WOA 原理 SCI二区|鲸鱼优化算法&#xff08;WOA&#xff09;原理及实现 2.OTSU多阈值图像分割模型 Otsu 算法&#xff08;最大类间方差法&#xff09;设灰度图像有 L L …
阅读更多...
项目升级Sass版本或升级Element Plus版本遇到的问题

项目升级Sass版本或升级Element Plus版本遇到的问题

项目升级Sass版本或升级Element Plus版本遇到的问题 如果项目有需求需要用到高版本的Element Plus组件&#xff0c;则需要升级相对应的sass版本&#xff0c;Element 文档中有提示&#xff0c;2.8.5及以后得版本&#xff0c;sass最低支持的版本为1.79.0&#xff0c;所升级sass、…
阅读更多...
数据结构 树1

数据结构 树1

目录 前言 一&#xff0c;树的引论 二&#xff0c;二叉树 三&#xff0c;二叉树的详细理解 四&#xff0c;二叉搜索树 五&#xff0c;二分法与二叉搜索树的效率 六&#xff0c;二叉搜索树的实现 七&#xff0c;查找最大值和最小值 指针传递 vs 传引用 为什么指针按值传递不会修…
阅读更多...
利用metaGPT多智能体框架实现智能体-1

利用metaGPT多智能体框架实现智能体-1

1.metaGPT简介 MetaGPT 是一个基于大语言模型&#xff08;如 GPT-4&#xff09;的多智能体协作框架&#xff0c;旨在通过模拟人类团队的工作模式&#xff0c;让多个 AI 智能体分工合作&#xff0c;共同完成复杂的任务。它通过赋予不同智能体特定的角色&#xff08;如产品经理、…
阅读更多...
嵌入式系统|DMA和SPI

嵌入式系统|DMA和SPI

文章目录 DMA&#xff08;直接内存访问&#xff09;DMA底层原理1. 关键组件2. 工作机制3. DMA传输模式 SPI&#xff08;串行外设接口&#xff09;SPI的基本原理SPI连接示例 DMA与SPI的共同作用 DMA&#xff08;直接内存访问&#xff09; 类型&#xff1a;DMA是一种数据传输接口…
阅读更多...
【MySQL】--- 复合查询 内外连接

【MySQL】--- 复合查询 内外连接

Welcome to 9ilks Code World (๑•́ ₃ •̀๑) 个人主页: 9ilk (๑•́ ₃ •̀๑) 文章专栏&#xff1a; MySQL &#x1f3e0; 基本查询回顾 假设有以下表结构&#xff1a; 查询工资高于500或岗位为MANAGER的雇员&#xff0c;同时还要满足他们的姓名首字母为…
阅读更多...
2 MapReduce

2 MapReduce

2 MapReduce 1. MapReduce 介绍1.1 MapReduce 设计构思 2. MapReduce 编程规范3. Mapper以及Reducer抽象类介绍1.Mapper抽象类的基本介绍2.Reducer抽象类基本介绍 4. WordCount示例编写5. MapReduce程序运行模式6. MapReduce的运行机制详解6.1 MapTask 工作机制6.2 ReduceTask …
阅读更多...
【memgpt】letta 课程6： 多agent编排

【memgpt】letta 课程6： 多agent编排

Lab 6: Multi-Agent Orchestration 多代理协作 letta 是作为一个服务存在的，app通过restful api 通信 多智能体之间如何协调与沟通？ 相互发送消息共享内存块，让代理同步到不同的服务的内存块
阅读更多...
cmd命令行无法进入D：盘怎么办

cmd命令行无法进入D：盘怎么办

我找到了一个方法就是 增加一个/d cd /d d: 如下图,我不仅可以进入d盘符下&#xff0c;还可以访问盘符下的文件夹
阅读更多...
【机器学习】自定义数据集 ，使用朴素贝叶斯对其进行分类

【机器学习】自定义数据集 ，使用朴素贝叶斯对其进行分类

一、贝叶斯原理 贝叶斯算法是基于贝叶斯公式的&#xff0c;其公式为&#xff1a; 其中叫做先验概率&#xff0c;叫做条件概率&#xff0c;叫做观察概率&#xff0c;叫做后验概率&#xff0c;也是我们求解的结果&#xff0c;通过比较后验概率的大小&#xff0c;将后验概率最大的…
阅读更多...
2025年人工智能技术：Prompt与Agent的发展趋势与机遇

2025年人工智能技术：Prompt与Agent的发展趋势与机遇

文章目录 一、Prompt与Agent的定义与区别（一）定义（二）区别二、2025年Prompt与Agent的应用场景（一）Prompt的应用场景（二）Agent的应用场景三、2025年Prompt与Agent的适合群体（一）Prompt适合的群体（二）Agent适合的群体四、2025年Prompt与Agent的发展机遇（一）Prompt的…
阅读更多...
2025_1_31 C语言中关于数组和指针

2025_1_31 C语言中关于数组和指针

1.数组作为指针传递 数组作为指针传递可以&#xff1a; 加一个数减一个数两个指针相减自增自减 int main() {int arr[] { 1,2,3,4,5,6,7,8,9 };printf("%d\n", arr[0] 2);printf("%d\n", arr[2] - 2);printf("%d\n", arr[0] arr[2]);int* …
阅读更多...
Baklib推动企业知识管理创新与效率提升的全面探讨

Baklib推动企业知识管理创新与效率提升的全面探讨

内容概要 在当今数字化转型的背景下&#xff0c;有效的知识管理显得尤为重要。知识是企业的核心资产&#xff0c;而传统的管理方式往往无法充分发挥这些知识的价值。因此&#xff0c;企业亟需一种高效、灵活的解决方案来应对这一挑战。Baklib作为一款先进的企业级知识管理平台…
阅读更多...
JAVA实战开源项目：网上购物商城(Vue+SpringBoot) 附源码

JAVA实战开源项目：网上购物商城(Vue+SpringBoot) 附源码

本文项目编号 T 041 &#xff0c;文末自助获取源码 \color{red}{T041&#xff0c;文末自助获取源码} T041&#xff0c;文末自助获取源码 目录 一、系统介绍二、演示录屏三、启动教程四、功能截图五、文案资料5.1 选题背景5.2 国内外研究现状5.3 可行性分析5.4 用例设计 六、核…
阅读更多...
访问CMOS RAM

访问CMOS RAM

实验内容、程序清单及运行结果 访问CMOS RAM&#xff08;课本实验14&#xff09; 代码如下&#xff1a; assume cs:code data segment time db yy/mm/dd hh:mm:ss$ ;int 21h 显示字符串&#xff0c;要求以$结尾 table db 9,8,7,4,2,0 ;各时间量的存放单元 data ends cod…
阅读更多...
Visual Studio使用GitHub Copilot提高.NET开发工作效率

Visual Studio使用GitHub Copilot提高.NET开发工作效率

GitHub Copilot介绍 GitHub Copilot 是一款 AI 编码助手&#xff0c;可帮助你更快、更省力地编写代码&#xff0c;从而将更多精力集中在问题解决和协作上。 GitHub Copilot Free包含哪些功能&#xff1f; 每月 2000 代码补全&#xff0c;帮助开发者快速完成代码编写。 每月 …
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023