重新认识JVM的内存分布(JDK11 + G1垃圾收集器)

JDK11+G1内存模型解析与调优实践 JVM内存模型是Java性能优化的核心基础,其演进反映了硬件架构和应用场景的变化趋势。以Region为单位的堆内存划分和元空间动态管理构成了现代JVM的内存管理基石,G1收集器通过智能Region分配实现停顿时间可控的垃圾回收。在JDK11环境下,结合-XX:MaxRAMPercentage等参数可实现容器化场景的自动内存适配,而MetaspaceReclaimPolicy等新特性显著提升了元空间利用率。针对电商、金融等对延迟敏感的场景,合理配置G1NewSizePercent等关键参数可使系统获得34%的 阅读详情

在这里插入图片描述

一、JVM内存分布全景图

JVM内存可以划分为以下四个核心部分(按逻辑分类):

JVM总内存 = 堆内存(Heap) + 非堆内存(Non-Heap) + 堆外内存(Off-Heap) + JVM Overhead

二、堆内存(Heap):G1的Region化管理

1. 堆内存定义

堆内存是 Java对象实例 的存储区域,由G1垃圾收集器统一管理。在JDK11中,堆内存通过 Region(区域) 划分,每个Region大小可配置(默认2MB~32MB)。

2. G1的堆内存结构

G1将堆划分为 年轻代(Young Generation) 和 老年代(Old Generation),两者均由Region组成:

  • 年轻代(Young):
    • Eden Region:新对象分配的区域,GC后存活对象移动到Survivor。
    • Survivor Region:存放年轻代GC后存活的对象,经历多次GC后晋升到老年代。
  • 老年代(Old):
    • 存放长期存活的对象或大对象(Humongous Object,超过Region大小50%的对象)。

3. 关键参数

  • -Xms / -Xmx:设置堆内存初始值和最大值(如 -Xms4g -Xmx8g)。
  • -XX:G1HeapRegionSize:设置Region大小(默认2MB~32MB)。

三、非堆内存(Non-Heap):元空间与代码缓存

1. 元空间(Metaspace)

  • 作用:存储 类的元数据(Class Metadata),如类结构、方法信息、常量池等。
  • JDK11特性:
    • 取代永久代(PermGen):JDK8及之后,元空间从堆内存移出,改为使用本地内存(Native Memory)。
    • 动态扩容:默认无上限,需通过 -XX:MaxMetaspaceSize 显式限制(如 -XX:MaxMetaspaceSize=512m)。
  • 典型问题:类加载过多(如动态代理、反射)可能导致 OutOfMemoryError: Metaspace。

2. 代码缓存(Code Cache)

  • 作用:存储 JIT编译器生成的本地机器码(Native Code)。
  • 默认大小:JDK11中默认为240MB(可通过 -XX:ReservedCodeCacheSize 调整)。
  • 典型问题:代码缓存耗尽时,JVM会抛出 CodeCache is full 错误,导致性能下降。

四、堆外内存(Off-Heap):脱离JVM管理的内存

1. 直接缓冲区(Direct Buffer)

  • 作用:通过 ByteBuffer.allocateDirect() 分配,用于NIO高效I/O操作。
  • 管理方式:由 sun.nio.ch.DirectBuffer 管理,通过 Reference 机制回收。
  • 风险:未正确释放可能导致内存泄漏(OutOfMemoryError: Direct buffer memory)。

2. JNI本地内存

  • 作用:Java通过JNI调用本地代码(C/C++)时分配的内存。
  • 典型问题:本地代码内存泄漏会导致进程内存耗尽(OutOfMemoryError: native memory)。

3. 第三方库缓存

  • 示例:Netty的堆外缓存池、数据库连接池的本地资源。

五、JVM Overhead:JVM自身运行的开销

1. 定义

JVM Overhead 是 JVM自身运行所需的内存开销,不包含堆内存和非堆内存中的显式区域。主要包括:

  • 线程栈:每个线程的私有内存(由 -Xss 控制,默认1MB)。
  • GC算法元数据:如G1的Region表、Remembered Set(RSet)、标记表。
  • JIT编译器运行时开销:编译队列、临时数据结构。
  • JVM内部缓存:如符号表、类加载器。

2. 线程栈的归属与影响

  • 归属:线程栈属于 JVM Overhead,而非非堆内存。
  • 影响:
    • 高并发场景下,线程数 × -Xss 会显著增加JVM Overhead。
    • 示例:500线程 × 1MB = 500MB。

3. 典型问题

  • 线程栈过大:高并发场景下,线程数 × -Xss 可能消耗大量内存(如500线程 × 1MB = 500MB)。
  • GC元数据膨胀:G1的Region数量增加会导致RSet占用更多内存。

六、关键概念澄清:线程栈的归属

1. 错误表述修正

  • 原错误:非堆内存中错误地将线程栈归类为非堆内存。
  • 修正后:
    • 非堆内存:仅包含元空间、代码缓存。
    • 线程栈:属于 JVM Overhead,不计入堆或非堆内存。

2. 线程栈的归属逻辑

内存类型是否包含线程栈说明
堆内存❌存储对象实例,不包含线程栈。
非堆内存❌包含元空间、代码缓存,不包含线程栈。
堆外内存❌用于直接缓冲区、JNI内存,不包含线程栈。
JVM Overhead✅线程栈属于JVM Overhead,是JVM运行时的内部开销。

七、JVM内存分布的监控与调优

1. 监控工具

  • jstat:监控堆内存使用(如 jstat -gc <pid>)。
  • jcmd:查看内存分配(如 jcmd <pid> VM.native_memory summary)。
  • jmap:生成堆转储(Heap Dump)分析内存泄漏。
  • VisualVM / JConsole:可视化监控堆、非堆、线程栈。

2. 调优参数

参数作用
-Xms / -Xmx设置堆内存初始值和最大值
-XX:MaxMetaspaceSize限制元空间最大值
-XX:MaxDirectMemorySize限制直接缓冲区最大值
-XX:ReservedCodeCacheSize调整代码缓存大小
-XX:NativeMemoryTracking=summary启用NMT监控堆外内存

八、实际案例:500线程应用的内存估算(基于指定参数)

1. 参数配置

-Xms4g -Xmx4g \           # 堆内存固定为4GB
-XX:MaxMetaspaceSize=512m \  # 元空间最大512MB
-XX:MaxDirectMemorySize=1g \ # 直接缓冲区最大1GB
-Xss1m \                  # 每个线程栈1MB

2. 内存分布计算

(1) 堆内存
  • 大小:4GB(固定值,不可扩展)。
  • 组成:
    • 年轻代(Young Generation):约1.5GB(默认G1的年轻代占比37.5%)。
    • 老年代(Old Generation):约2.5GB。
(2) 非堆内存(Non-Heap)
  • 元空间(Metaspace):512MB(显式限制)。
  • 代码缓存(Code Cache):默认240MB(JDK11默认值)。
  • 总计:512MB + 240MB = 752MB。
(3) 堆外内存(Off-Heap)
  • 直接缓冲区(Direct Buffer):1GB(由 -XX:MaxDirectMemorySize=1g 限制)。
  • JNI内存:假设无显著泄漏,按需分配。
  • 总计:1GB。
(4) JVM Overhead
  • 线程栈:500线程 × 1MB = 500MB。
  • GC元数据(G1的Region表、RSet等):约 1.2GB(堆大小4GB时典型值)。
  • JIT编译器运行时开销:约 200MB。
  • 其他JVM内部开销(符号表、类加载器等):约 100MB。
  • 总计:500MB + 1.2GB + 200MB + 100MB = 2GB。

3. 总内存估算

总内存 = 堆内存 + 非堆内存 + 堆外内存 + JVM Overhead
       = 4GB(堆) + 752MB(非堆) + 1GB(堆外) + 2GB(Overhead)
       ≈ **7.75GB**

注:这里计算出来的是值是jvm进程内存开销上限,因为上面这些参数MaxMetaspaceSize,MaxDirectMemorySize只是设置了上限,并不表示进程一启动就占用了这么多


九、调优策略

1. 线程栈优化

  • 当前配置:500线程 × 1MB = 500MB。
  • 优化建议:
    • 若线程数较多,可调低 -Xss(如 -Xss512k),节省内存。
    • 避免线程泄漏(如未关闭的线程池)。

2. 直接缓冲区管理

  • 监控命令:
    jcmd <pid> VM.native_memory summary
    
  • 优化建议:
    • 限制直接缓冲区大小(已配置为1GB)。
    • 确保 ByteBuffer 正确释放(调用 ByteBuffer#free() 或使用 try-with-resources)。

3. 元空间监控

  • 风险:类加载过多可能导致 OutOfMemoryError: Metaspace。
  • 监控命令:
    jstat -gc <pid>
    

4. 容器内存限制

  • 建议:若部署在容器中,需设置内存限制(如 --memory=8g),确保 7.75GB < 8GB。

十、总结

内存类型大小说明
堆内存4GB存储Java对象实例,固定值。
非堆内存752MB元空间(512MB) + 代码缓存(240MB)。
堆外内存1GB直接缓冲区(1GB),需监控NIO使用。
JVM Overhead2GB线程栈(500MB) + GC元数据(1.2GB) + JIT开销(200MB) + 其他(100MB)。

十一、附录:关键参数说明

参数作用
-Xms4g -Xmx4g堆内存固定为4GB,避免动态扩展。
-XX:MaxMetaspaceSize=512m限制元空间最大值为512MB,防止类加载导致OOM。
-XX:MaxDirectMemorySize=1g限制直接缓冲区为1GB,避免堆外内存溢出。
-Xss1m每个线程栈1MB,500线程共占用500MB。

Logstash 性能调优实战:从频繁 Full GC 到高吞吐,JVM 与管道参数全解析 在分布式日志采集与处理系统中,JVM 内存管理和垃圾回收(GC)机制是影响服务稳定性的核心因素。Logstash 作为 ELK 技术栈中的关键组件,其底层的 JRuby 运行时决定了所有事件处理都受 JVM 堆与 GC 行为的影响。当面对高吞吐日志流时,频繁的 Full GC 会导致处理停滞、Kafka 消费滞后,直接威胁业务可观测性。理解 JVM 堆结构、G1 收集器工作原理以及 Logstash 管道参数(如 pipeline.workers 与 batch.size)的联动关系,是系统性优化性能的前提 阅读详情

相关推荐

JDK11的底层原理

JDK 11作为Java平台的长期支持版本,带来了大量的性能提升和新的功能。从JVM架构、垃圾回收器的改进,到模块化系统和标准化的HTTP客户端API,JDK 11在底层原理上进行了深度优化,致力于提供更高效、更稳定的运行环境。通过对这些特性的理解,开发者可以更好地优化应用程序的性能,利用JDK 11的强大功能来构建更高效的Java应用。

LiRongdongPlus的博客 186

JVM — JDK11垃圾回收器 ZGC

ZGC(The Z Garbage Collector)是 JDK 11 中推出的一款低延迟垃圾回收器,为实现以下几个目标而诞生的垃圾回收器,停顿时间不超过 10ms,停顿时间不会因堆变大而变长,支持 8MB~4TB 级别的堆(未来支持 16TB)ZGC 作为下一代垃圾回收器,性能非常优秀。ZGC 垃圾回收过程几乎全部是并发,实际 STW 停顿时间极短,不到 10ms。这得益于其采用的着色指针和读屏障技术。

qq_38658567的博客 3825

JVM性能调优实战:G1/ZGC参数协同与元空间泄漏治理

JVM内存模型本质是运行时资源调度协议,而非静态分区图谱;垃圾回收的核心在于吞吐量与延迟的动态平衡,其效果取决于GC算法原理、参数协同机制及应用对象生命周期特征。G1 GC通过Region化管理实现混合回收,ZGC依托着色指针达成亚毫秒停顿,但二者均需匹配硬件约束与业务负载模式。元空间替代永久代后,类卸载依赖Full GC触发,易引发动态代理场景下的隐式泄漏。掌握jstat指标解读、Arthas运行时诊断与G1HeapWastePercent/G1MixedGCCountTarget等关键参数调优逻辑,是构

weixin_32821533的博客 169

JVM垃圾回收相关算法

垃圾回收相关算法标记阶段标记阶段:引用计数算法循环引用举例小结标记阶段:可达性分析算法概念思路GC Roots可以是哪些?对象的finalization机制描述注意对象三个状态具体过程MAT与JProfiler的GC Roots溯源MAT是什么?命令行使用 jmap使用JVIsualVM使用MAT打开Dump文件JProfiler的GC Roots溯源如何判断什么原因造成OOM清除阶段标记-清除算法执行过程什么是清除?缺点复制算法背景核心思想优点缺点标记-整理算法背景执行过程标清和标整的区别优点缺点小结扩展

fanjia2shao的博客 428

[南大ICS]PA1 - 开天辟地的篇章: 最简单的计算机

task PA1.1: 实现单步执行, 打印寄存器状态, 扫描内存 task PA1.2: 实现算术表达式求值 task PA1.3: 实现所有要求, 提交完整的实验报告

qq_42474104的博客 1571

AI工程化之生成式UI & A2UI(一)

本文系统介绍了生成式UI和Google A2UI技术。生成式UI通过AI直接生成前端代码(完全生成式)或DSL(混合式),实现千人千面的动态界面和研发提效。Google A2UI提出组件级和消息级协议,采用JSON规范实现渲染框架解耦,支持多端渲染。文章详细阐述了A2UI的架构设计,包括协议生成、服务端处理和渲染器实现,并对比了与传统前端框架的差异,指出A2UI本质是UI=F(AI(UI)+AI(state))的创新模式。最后通过playground项目展示了A2UI的实践应用。

qq_34306228的博客 593

JVM 内存模型 、对象分配流程、 垃圾收集器

Jvm内存模型、对象创建流程、垃圾收集器 serial 单线程收集器, 简单高效, 收集过程会有 STW, 用于新生代。 使用复制算法 serial 的老年代版本:serial old 单线程收集器, 简单高效, 收集过程会有 STW, 用于老生代。 使用标记-整理算法 ParNew 多线程版本, 多核, 收集过程会有 STW,但是停顿时间减少,吞吐量更大 业务代码时间 / (业务代码时间+垃圾收集时间) = 吞吐率 99s / 99s + 1s(垃圾收集时...

qiu7213的博客 1143

Viobot使用教程总贴

使用教程总贴

weixin_66666206的博客 1411

JDK11-JVM参数配置详解

如果开启类指针压缩,+UseCompressedClassPointers,根据上面的条件,结果跟只开启UseCompressedOops一样,会在内存中消耗20个字节,o指针占4个字节,Object对象占16个字节。通过 -XX:ReservedCodeCacheSize参数可以指定Code Cache的初始化大小,这个默认值在不同的JDK版本也不同,目前我这边调试的是OpenJDK11,默认大小是240M,这个已经够用了。SecureRandom在java各种组件中使用广泛,可以可靠的产生随机数。...

sebeefe的博客 2806

Android 桌面小组件 AppWidgetProvider

桌面小组件,绝对是小程序中的小程序,说白了就是任何复杂一丁点的操作都适合做成桌面小组件。所以这里采用的演示的例子,就只有一个白色圆角背景,外加一个文本框,显示文字。小组件的教程网上一搜一大堆,所以我这里主要就是介绍一些坑的地方,跟大致处理流程,具体细节还得看其他大神的骚操作。

qq_33601179的博客 6585

人形机器人解耦驱动腿部设计与FAST性能优化

机器人运动控制的核心在于动力学解耦与能量效率优化。通过多连杆机构设计,可以实现关节运动的独立控制,显著降低惯性叠加和能量损耗。DecARt Leg采用创新的齿轮-四杆复合机构,将腿部伸缩与摆动运动完全解耦,配合多杆踝关节传动系统,实测行走速度可达4.18m/s。这种解耦设计不仅提升了动态性能,其提出的FAST指标更为腿部构型提供了量化评估基准,在仓储物流、地形适应等场景展现出显著优势,为人形机器人运动控制提供了新的技术路径。

weixin_33759613的博客 241

JVM 调优参数介绍

jvm参数 -Xms 堆最小值 -Xmx 堆最大堆值。-Xms与-Xmx 的单位默认字节都是以k、m做单位的。通常这两个配置参数相等,避免每次空间不足,动态扩容带来的影响 -Xmn 新生代大小 -Xss 每个线程池的堆栈大小。在jdk5以上的版本,每个线程堆栈大小为1m,jdk5以前的版本是每个线程池大小为256k。一般在相同物理内存下,如果减少-Xss值会产生更大的线程数,但不同的操作系统对进程内线程数是有限制的,是不能无限生成 -XX:NewRatio 设置新生代与老年代比值,-XX:NewR

vincent_wen0766的博客 898

electron:解决打包后报错Cannot find module ‘X‘ 运行报错各种模块缺失问题(解决electron build打包后运行应用报错启动失败或白屏,无论模块名称是什么都能解决!)

Electron app打包后启动报错:“Cannot find module 'X'”解决方案,electron-builder 打包出现 cannot find module,electron 打包后找不到module问题,electron打包运行白屏、Can not find modules ‘x‘,electron项目打包报错,electron打包后,点击生成的exe应用程序出现Cannot find module,解决electron-build打包后运行app报错:cannot find mod

✅ 精选推荐文章 4386

JDK11与G1下的JVM内存分布:从Region模型到线上排障

JVM内存分布是Java性能调优与故障排查的基石。传统连续分代模型在JDK11配合G1垃圾收集器时已不再适用——堆被划分为大量Region格,Eden、Survivor、Old与Humongous动态流转。理解这一原理,才能看懂对象从TLAB分配到晋升老年代的完整路径,也才能正确解读jcmd、jstat输出。在实际生产环境中,频繁Full GC、Metaspace超限、物理内存吃紧往往与Region分布失衡、大对象Humongous占用过高、直接内存忽视有关。掌握G1自适应机制与关键参数,避免手动固定新生代

weixin_31412781的博客 131

IO Virtualization with Virtio.part 2 [十三]

通过对virtio_device_id 中的 device 和 vendor 的值进行比较,我们找到对应的 virtio 驱动,由于这里我们使用 i2c virtio 为例,所以调用 virtio_i2c_probe 进行 virtio i2c 设备的初始化。在和 virtio mmio 设备交互时我们会读取 VIRTIO_MMIO_DEVICE_ID 和 VIRTIO_MMIO_VENDOR_ID,并将其值写入 virtio_device_id 中,这个就会用作后面和 virtio 设备驱动的匹配参数。

cxjczy1990的博客 1212

10倍开发者的 Dify 魔法书:从零构建全栈 AI 应用

“不懂底层算法,也能开发爆款 AI 应用吗?” 答案是:绝对可以。 Dify 正在重新定义 AI 应用的开发范式——通过可视化的低代码平台,将原本需要数周的开发周期压缩到几小时。无论你是前端、后端、产品经理,还是渴望破局的独立开发者,这都是你不可错过的红利。 我们将手把手教你利用 Dify 快速接入百模大战,零代码搭建企业级知识库,并一键发布你的专属 AI 助手、智能客服和自动化工作流。 告别重复造轮子,掌握 Dify,一个人就是一支 AI 团队。现在上车,开启你的 10 倍速开发之旅!

davidwang456的专栏 685

JDK11 G1垃圾收集器内存管理与调优实战

垃圾收集器是Java虚拟机(JVM)内存管理的核心组件,其设计直接影响应用性能表现。G1(Garbage-First)作为JDK9后默认的垃圾收集器,采用基于Region的堆内存布局取代传统分代模型,通过将堆划分为等大小Region实现更精细的内存管理。这种设计支持动态区域类型转换,避免全堆回收的同时实现可预测的停顿时间。在JDK11环境下,合理配置-XX:MaxGCPauseMillis和-XX:InitiatingHeapOccupancyPercent等关键参数,配合jstat、jmap等工具监控GC

weixin_29698641的博客 260

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

JDK11 + G1下的JVM内存布局与对象分配:从原理到排查

Java性能调优中,JVM内存模型是开发者必须打牢的基础。从传统堆、栈、方法区的认知出发,JDK11时代的内存管理已发生深刻变化:永久代被元空间取代,G1收集器将堆划分为Region,以可预测停顿为目标进行回收。理解对象分配路径、TLAB机制、指针压缩与Humongous对象等原理,能帮助定位内存溢出、频繁GC等实际问题。在实际运维与调优场景中,结合jstat、GC日志和JFR观测G1的堆布局与RSet开销,可有效避免因大对象或压缩指针失效导致的性能劣化。围绕JDK11 + G1,系统梳理内存区域划分、对象

weixin_30402231的博客 211

霍尼韦尔SoftMaster使用说明

霍尼韦尔SoftMaster使用说明

lwip-2.0.3

lwip是瑞典计算机科学院(SICS)的Adam Dunkels 开发的一个小型开源的TCP/IP协议栈。实现的重点是在保持TCP协议主要功能的基础上减少对RAM 的占用。

Java字符串常量池深度解析:内存分布、JDK演进与实战调优

字符串常量池是Java中管理字符串字面量的核心内存机制,其本质是堆内受控的哈希表结构,而非独立内存池。它基于开放寻址法实现,哈希计算依赖对象地址而非内容,直接影响==比较语义和intern()行为。从JDK6永久代到JDK7+堆内存的迁移,彻底改变了GC策略与OOM排查逻辑;而字符串去重(String Deduplication)和分片(Sharding)等现代优化,则进一步提升高并发场景下的稳定性与性能。理解其在JVM内存模型中的真实位置、扩容阻塞特性及与G1/ZGC的协同机制,对解决线上内存泄漏、JSO

weixin_30374009的博客 545

JVM垃圾回收实战:从CMS到G1,如何选择最适合你的GC策略?

本文深入探讨JVM垃圾回收策略选择,重点对比CMS与G1收集器的性能特点及适用场景。通过实战配置示例和调优技巧,帮助开发者根据业务需求(如电商大促、金融交易等)选择最优GC策略,提升应用吞吐量并降低停顿时间。

weixin_30872499的博客 424

JVM参数调优

通过调优,增加年轻代的大小(-Xmn),减少老年代对象晋升的频率,同时切换到G1垃圾收集器(-XX:+UseG1GC),并调整G1的区域大小(-XX:G1HeapRegionSize)和初始化暂停目标(-XX:MaxGCPauseMillis),可以有效减少GC暂停时间,提高系统的响应速度和稳定性,从而提升用户体验。内存分配:调整年轻代、老年代以及各个区(如Eden、Survivor)的大小,以适应应用的对象生命周期特性,减少对象跨代晋升,优化内存使用。直觉分析:响应时间延长:是否与频繁GC有关;

weixin_37641863的博客 787

JVM垃圾收集器及常用的垃圾收集算法

在Java成为如今炙手可热的编程语言之一,主要原因就包括虚拟机成功引入GC收集这项技术。Java的内存管理避免了绝大多数内存泄漏的问题,同时也让程序员能更专心的处理业务逻辑。每每看到这样话的时候,心里其实无数头马儿奔腾而过。在实际的编码过程中,关于GC收集的事情基本上确实没有考虑过,也做到了专心处理业务逻辑,呵呵呵。不过面试过程关于垃圾收集部分的面试题确实是如剥洋葱一样,一个层接着一...

anyway8090的博客 284

jvm虚拟机

jvm内存模型

a123op2346的博客 179

JVM常见问题总结

针对JVM常见问题的总结,主要就是分为JVM内存模型、类加载系统、垃圾回收几个部分,主要参考周志明老师的《深入理解Java虚拟机》一书JVM内存结构指的是JVM运行时数据区的内存分布,共分为五个部分,分别是虚拟机栈、本地方法栈、程序计数器、堆和方法区,其中虚拟机栈,本地方法栈和程序计数器是线程私有的,堆和方法区是线程共享的。对这些分区的接受如下:堆区是用来存放Java对象的地方,我们的Java对象基本都是存放在堆中,同时堆区也是JVM垃圾回收最频繁的地方,可能出现OOM方法区主要存放了类型数据,存在垃圾回收

wait2023的博客 686

Java~阅读《深入理解Java虚拟机》知识点总结

文章目录前言第一部分(Java程序内部机制)1.1Java运行时一个类是什么时候被加载的?1.2JVM一个类的加载过程?1.3一个类被初始化的过程的注意点1.4继承时父子类的初始化顺序是怎样的?1.5究竟什么是类加载器?1.6JVM有哪些类加载器?1.7JVM中不同的类加载器加载哪些文件?1.8JVM三层类加载器之间的关系是继承吗?1.9你了解JVM类加载的双亲委派模型吗?1.10JDK为什么要设计双亲委派模型,有什么好处?1.11可以打破JVM双亲委派模型吗?如何打破JVM双亲委派模型?1.12如何自定义

Shangxingya的博客 2782

JVM总结

JVM1.JVM总结 1.JVM总结

weixin_43766298的博客 745
上一篇: AIGC入门,在Mac上基于Ollama和phi3:mini的完整Agent/Subagent例子
下一篇: 一步步教你用 venv 管理python环境
明月(Alioo)
博客等级 码龄18年 267粉丝 207原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

明月(Alioo)

你的鼓励将是我创作的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值