标签 Gopher 下的文章

Go开发者必看!JetBrains 2024报告深度解读:Go语言现状、趋势与未来机遇

本文永久链接 – https://tonybai.com/2025/04/10/jetbrains-2024-go-report-analysis

嘿,各位Gopher!

你是否也在关心Go语言的最新动态?它还在快速增长吗?薪资水平如何?未来方向在哪?

这是我看到的关于2024年Go语言发展趋势最全面、数据最翔实的一份报告解读。 JetBrains,这家开发者们都非常熟悉的工具公司,最近发布了《Is Golang Still Growing? Go Language Popularity Trends in 2024》的研究报告文章。如果你是Go开发者,或者正在关注Go生态,这篇文章就是为你准备的,强烈推荐阅读!

在深入细节之前,先为你快速提炼报告的核心发现,让你高效把握重点:

  • Go开发者规模依旧庞大且专业: 全球专业Go开发者估算超400万,且持续增长。
  • 云原生主战场地位稳固: Web服务、云服务、IT基础设施是Go应用核心领域。
  • “钱景”诱人: Go开发者薪资普遍处于行业较高水平
  • 各大榜单表现亮眼: 在TIOBE、GitHub Octoverse等多个权威榜单中,Go排名稳定或显著上升
  • 与Rust互补而非替代: 两者定位不同,常被结合使用。
  • 未来聚焦: 持续深耕云原生,并在GenAI基础设施领域崭露头角。

Go开发者画像:规模、角色与“钱景”

报告显示,全球使用Go的专业开发者规模可观。JetBrains估计近一年有410万专业人士使用Go,其中180万将其作为主要语言之一。SlashData的估算则更高,达到470万(包含学生和爱好者),而最新的Stack Overflow和SlashData数据推算更是达到了580万

从上图中展示的开发者从事的软件类型来看:

  • Web服务 (无GUI): 744,000
  • 网站: 732,000
  • 云服务: 681,000

开发者角色方面(如上图),除了大量的软件工程师/程序员 (约160万)外,DevOps/基础设施工程师(约50万)的比例也相当高,这凸显了Go在云原生基础设施和运维领域的巨大需求。

更让Gopher们关心的是薪资。报告明确指出,Go开发者是业内薪资最高的人群之一。美国Go开发者的平均年薪约为$76,000,经验丰富者甚至可达$500,000


Go的应用版图:核心场景与行业分布

Go最常见的两大用例依然是:

  1. API/RPC服务(75%)
  2. 命令行工具(62%)

哪些行业在重度使用Go呢?

  • 科技 (超过40%): Google, DataDog, K8s, HashiCorp, Dropbox, Salesforce, Apple…
  • 金融服务 (13%): Monzo, American Express, Mercado Libre…
  • 交通与零售 (10%): Amazon, Uber, DeliveryHero, HelloFresh…
  • 媒体/游戏 (7%): Netflix, Bytedance, Tencent, Reddit, Snap…

多维数据透视:Go在各大榜单上的表现

担心Go的热度?来看看它在各大权威榜单上的表现吧:

  • JetBrains语言潜力指数: Go排名 第4,仅次于TypeScript, Rust, Python,显示出强大的增长潜力和用户粘性。
  • Stack Overflow开发者调查: 在“受喜爱和期望” (Admired and Desired) 榜单中,Go从去年的第9位跃升至第7位,超过了C#和Shell。
  • GitHub Octoverse: 稳定保持在 Top 10 编程语言之列,并且是 Top 3增长最快的语言之一 (开源项目活跃度)。
  • Cloudflare Radar (API客户端语言): Go在2024年 超越Node.js,成为自动化API请求最常用的语言,占比约12% (去年为8.4%)。
  • TIOBE指数: Go从2023年的第13位大幅攀升至第7位,达到自2009年以来的最高排名!**


TIOBE 2025.04榜单

这些数据有力地证明,Go语言不仅没有衰退,反而在多个维度上保持着强劲的势头。


Go vs Rust:是对手还是队友?

报告特别提到了Go与同样热门的Rust的关系。结论是:它们更多是互补,而非直接竞争

  • Go: 更易上手,开发效率高,非常适合云服务、微服务、API、CLI开发,强调 快速开发和可伸缩性
  • Rust: 性能极致,适用于性能密集型、底层嵌入式开发,但复杂性更高,开发成本和时间也更高

许多公司会同时使用这两种语言,根据场景需求选择最合适的工具。对Rust感兴趣的Go开发者增多,并不意味着Go市场份额的下降。


Go的未来之路:聚焦云原生与拥抱GenAI

展望未来,Go团队将继续聚焦云原生领域,满足其对开发效率 (time to value)、可靠性和可伸缩性的核心需求。

一个令人兴奋的新方向是生成式AI (GenAI) 基础设施。虽然Go在传统机器学习领域不如Python,但其在性能和可伸缩性上的优势,使其成为构建AI模型服务 (model serving)等生产级AI基础设施的理想选择。

  • 主流AI平台 (OpenAI, Google AI等) 已提供Go SDK
  • Go的GenAI生态正在成长,涌现出如Ollama, LangChain Go, kserve等工具。
  • GenAI基础设施本身,就像云基础设施一样,正在越来越多地用Go编写。

报告还提到,Go项目领导层虽有变动(Russ Cox卸任,Austin Clements和Cherry Mui接任),但新领导层对Go的理念和目标有深刻理解,确保了项目的连续性和稳定性。Go 1.24已于2025年2月发布,未来可期。


总结:黄金时代,未来可期

总而言之,JetBrains这份详尽的报告描绘了一个清晰的画面:

2024年,Go语言不仅保持了稳定发展,更在云原生领域巩固了核心地位,并在GenAI基础设施等新兴领域展现出强劲潜力。它正步入一个成熟且充满机遇的“黄金时代”

对于Gopher们来说,持续深耕云原生,关注Go在AI基础设施的应用,无疑是明智的选择。

那么,你认为Go语言的下一个增长点会在哪里?你对Go的未来有什么看法?

欢迎在评论区留下你的真知灼见,一起交流探讨!


Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且,2025年将在星球首发“Gopher的AI原生应用开发第一课”、“Go陷阱与缺陷”和“Go原理课”专栏!此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格6$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.25新提案:GOMAXPROCS默认值将迎Cgroup感知能力,终结容器性能噩梦?

本文永久链接 – https://tonybai.com/2025/04/09/gomaxprocs-defaults-add-cgroup-aware

Go官方出手!新提案自动优化容器内GOMAXPROCS,告别性能噩梦!

在Kubernetes等容器环境中运行Go应用时,一个常见的性能陷阱悄然存在:默认的GOMAXPROCS值基于节点CPU核心数,而非Pod的CPU限制(limit),导致资源争抢和性能下降。近期一篇广受关注的博客文章“Golang Performance Penalty in Kubernetes”通过实测数据揭示了这一问题带来的显著延迟增加(高达65%+)和吞吐量降低(近20%)。

不过近期,Go核心团队带来一则好消息,Go Runtime团队的Michael Pratt已正式提出一项提案(#73193),旨在让Go运行时默认感知Linux Cgroup的CPU quota限制并自动调整GOMAXPROCS值,该提案有望在Go 1.25中为开发者带来开箱即用的性能优化,告别在容器或Kubernetes中手动配置GOMAXPROCS的烦恼。

在这篇文章中,我会对当前GOMAXPROCS默认值在云原生环境引发的性能问题以及Pratt的提案做一个详细说明,供广大Gopher们参考。

1. 容器中GOMAXPROCS的“水土不服”与性能代价

Go 1.5版本起,GOMAXPROCS默认设置为“可用的CPU核心数”(综合考虑机器核心数和CPU亲和性设置)。这在单租户或资源不受严格限制的环境下工作良好。然而,在普遍使用Cgroup进行资源隔离的容器化部署场景中,这一默认行为却常常与Pod的实际CPU限制limits.cpu)产生严重错位,引发一系列性能问题。

想象一下:一个Go应用部署在拥有32个vCPU的K8s节点上,但其Pod的limits.cpu被设置为1。Go运行时看到的是32核,于是默认将GOMAXPROCS设为32。这意味着Go运行时会尝试并发运行多达32个操作系统线程来执行Go代码,而Kubernetes(通过Cgroup的CPU Quota机制)却严格限制该Pod在每个调度周期内(如100ms)只能使用相当于1个CPU的计算时间。

这会带来什么后果? 正如Mansoor Majeed在其博客文章《Golang Performance Penalty in Kubernetes》中通过基准测试所生动展示的:

  • 过度的上下文切换

32个活跃的Go线程争抢远少于此的可用CPU时间片(在此例中仅相当于1个CPU的时间),迫使操作系统内核进行大量、且低效的线程上下文切换。在他的测试中,错误配置GOMAXPROCS的场景下,上下文切换次数(context_switches_total)相比正确配置时飙升了近4倍(从约6.5k/s 增加到30k/s)。

  • CPU配额扼杀(Throttling)与调度延迟

应用(尤其CPU密集型任务,如博客中的Fibonacci计算)的并发线程迅速耗尽Cgroup分配的CPU时间配额(cpu.cfs_quota_us)。一旦耗尽,内核将强制暂停该Cgroup内所有线程的执行,直到下一个调度周期(cpu.cfs_period_us)开始。这直接导致了请求处理的延迟尖峰。博客中的”Process Schedule Stats”图表也显示,错误配置下,进程等待CPU的时间(Waiting for CPU)出现了高达34秒的峰值,而正确配置下仅约900毫秒。

  • 应用性能显著下降

过度的上下文切换和频繁的CPU Throttling共同作用,导致应用端到端的性能大幅降低。博客的wrk基准测试显示,在CPU密集场景下,与正确设置GOMAXPROCS=1相比,使用默认GOMAXPROCS=32(基于节点而非Pod限制)导致的性能下降如下图所示:

我们看到:平均请求延迟增加了65% (从 20ms 上升到 33ms),最大请求延迟增加了82% (从255ms飙升到465ms)。整体RPS (每秒请求数) 下降了近20% (从50213减少到40356)。

  • GC 放大问题

Go的并发垃圾回收器(GC)的工作量与GOMAXPROCS挂钩。GC目标是使用25%的P(对应GOMAXPROCS数量)进行后台标记工作,并在空闲的P上运行额外的 idle worker。过高的GOMAXPROCS会导致GC期间产生远超实际可用CPU资源的并发请求,极易触发或加剧CPU配额扼杀,即使在非GC期间应用本身运行平稳。极端情况下,由于内核调度,可能出现大量GC worker同时运行,短暂“冻结”用户goroutine的执行。

  • 运行时扩展性成本

运行更高的GOMAXPROCS会带来额外的运行时开销,例如每个P的本地缓存(如mcache)导致的内存占用增加,以及P之间进行工作窃取、GC协调等所需的同步成本。当GOMAXPROCS远大于实际可用CPU时,这些成本被白白支付,却无法带来相应的并行处理收益。

容器中GOMAXPROCS默认设置为节点CPU数量这个问题在Go社区存在已久,相关讨论见于#33803。目前,开发者通常采用以下方式规避:

  • 手动设置环境变量

比如:在Kubernetes Deployment YAML中,通过valueFrom: resourceFieldRef将GOMAXPROCS环境变量显式设置为Pod的limits.cpu值,下面是一个示例:

spec:
  containers:
  - name: my-go-app
    image: my-go-app:latest
    env:
    - name: GOMAXPROCS
      valueFrom:
        resourceFieldRef:
          # Ensure the resource name matches your limit spec
          resource: limits.cpu
          # Use divisor 1 for whole cores, or adjust if using millicores
          # and need integer conversion logic (though GOMAXPROCS needs integer)
          # Often, just referencing limits.cpu works if it's a whole number.
          # For fractional limits resulting in non-integer GOMAXPROCS,
          # manual calculation or automaxprocs might be better.
          divisor: "1"
    resources:
      limits:
        cpu: "2" # Example limit
      requests:
        cpu: "100m"
  • 使用第三方库

在Go代码中引入如uber-go/automaxprocs这样的库,它会在应用启动时自动检测Cgroup v1或v2的CPU限制,并相应地调用runtime.GOMAXPROCS()进行设置。

import _ "go.uber.org/automaxprocs"

func main() {
    // automaxprocs automatically adjusts GOMAXPROCS during init
    // ... rest of your application
}

虽然有解决方案,但这需要开发者意识到问题的存在并主动采取措施,增加了配置负担和潜在的疏漏风险。近期Go官方终于有针对此问题的动作了,我们来详细看看官方的方案。

2. 官方提案:让GOMAXPROCS自动适配CPU Limit

为了一劳永逸地解决这个问题,并提供更优的开箱即用体验,Go核心团队成员pratt在#73193中提出了一个具体的解决方案,旨在将Cgroup CPU limit感知能力内置到Go运行时中。下面也简单说一下Pratt给出的方案的核心机制,包括以下几点:

  • 自动检测CPU Limit

在程序启动时,如果用户未通过环境变量GOMAXPROCS指定值,Go运行时(仅在Linux 上)将主动检测以下三项:

(a) 机器的总CPU核心数: 通过runtime.NumCPU()的底层机制获取。
(b) CPU亲和性限制: 通过sched_getaffinity(2) 系统调用获取当前进程允许运行的CPU核心集合大小。
(c) Cgroup CPU Quota限制: 运行时会查找进程所属的Cgroup层级结构(支持v1和v2,以及混合模式)。对于每一层级,它会读取cpu.cfs_quota_us 和cpu.cfs_period_us(v1) 或cpu.max(v2) 文件。计算出每一层的CPU limit(等效核心数=quota/period)。最终取整个层级路径上的最小值作为该进程的“有效CPU limit”。

  • 计算新的默认GOMAXPROCS

新的默认GOMAXPROCS值将是上述(a)、(b)、(c)三者计算结果中的最小值。特别地,由(c)计算出的Cgroup limit值在用于最终比较前会经过一个调整:adjusted_cgroup_limit = max(2, ceil(effective_cpu_limit))。即,先向上取整,然后确保结果至少为2。

  • 自动更新

为了适应CPU限制或亲和性可能在运行时发生变化的情况(例如 Kubernetes的 “in place vertical scaling” 特性允许动态调整Pod的limits.cpu),Go运行时将引入一个后台机制(可能在sysmon协程中实现),以较低频率(例如,提案建议最小周期30秒,最长1分钟)定期重新检查CPU亲和性设置和Cgroup的CPU quota文件。如果检测到变化导致计算出的默认GOMAXPROCS值改变,运行时将自动调用内部的GOMAXPROCS设置函数进行更新。

  • 引入新的API

该提案还引入了一个新的公共API:runtime.SetDefaultGOMAXPROCS()。调用此函数会立即触发一次上述默认值的计算和设置过程,忽略GOMAXPROCS 环境变量的影响。这可以用于覆盖启动时通过环境变量设置的值,恢复到运行时自动检测的行为。同时,在得知外部环境(如Cgroup 配置)发生变化后,主动强制进行一次更新,而不必等待后台的自动扫描。

  • 兼容性控制

这是一个可能改变现有程序行为的变更。为了提供平滑的过渡和控制能力,该新行为将由一个GODEBUG标志cgroupgomaxprocs=1控制。根据Go的GODEBUG兼容性策略,对于go.mod文件中指定的Go语言版本低于引入该特性的版本(预计是Go 1.25),该标志默认为0 (禁用新行为,保持现状)。只有当项目将其go.mod中的Go版本升级到1.25或更高时,默认值才会变为1 (启用新行为)。开发者仍然可以通过设置GODEBUG=cgroupgomaxprocs=0 来显式禁用新行为。

3. 其他设计考量与细节

经过#33803几年的讨论,Pratt在新提案中也谈及了一些设计考量和细节,这里也就一点典型的问题做一下梳理:

  • 为何是Limit而非Shares/Request?

Cgroup的cpu.shares(v1)或cpu.weights(v2)(对应Kubernetes的CPU Request)定义的是资源竞争时的相对优先级,而不是硬性的CPU使用上限。当系统负载不高时,仅设置了Request 的容器可能使用远超其Request值的CPU。因此,Shares/Weights不适合作为限制并行度的GOMAXPROCS的依据。Java和.NET在其运行时中进行容器资源感知的实践也得出了类似的结论,它们都选择基于CPU Quota(Limit)。

  • 处理分数Limit(Rounding)

Cgroup Quota可以设置成分数形式(如limits.cpu:”1500m”对应1.5核)。由于GOMAXPROCS必须是整数,提案选择向上取整 (ceil)。例如,1.5会变成2。这样做的考虑是,允许应用利用Cgroup提供的突发能力,并且可能更好地向监控系统指示CPU饥饿状态。然而,这与uber-go/automaxprocs默认向下取整 (floor) 的策略不同。后者认为分数部分的配额可能是为容器内的辅助进程(如sidecar、监控agent)或C库线程预留的,向下取整更保守,避免Go进程完全用尽配额。这是一个开放的讨论点,最终实现可能会根据社区反馈调整。

  • 最小值为2的理由

提案建议将通过Cgroup limit计算出的值(向上取整后)与2比较,取较大者。即,即使CPU limit小于1(如0.5),最终也会至少设置为2。这样做的主要原因是GOMAXPROCS=1会完全禁用Go调度器的并行性,可能导致一些意想不到的性能问题或行为怪异,例如GC worker可能在运行时暂时“暂停”用户Goroutine(因为只有一个P可以运行,需要在用户代码和GC代码间切换)。设置至少为2可以保留基本的并行能力,更好地利用Cgroup允许的突发性。当然,如果物理核心数或CPU亲和性限制本身就是1,那么根据前面的计算规则,最终GOMAXPROCS仍然会是1。

  • 日志

与automaxprocs提供可选的日志输出不同,该提案的内置实现默认不打印关于GOMAXPROCS被自动调整的日志信息,以保持运行时输出的简洁性。

4. 小结

这项针对Go运行时的提案(#73193) 若能在Go 1.25实现,将为容器化环境中的Go应用带来实质性改进。其核心优势在于开箱即用的性能优化:通过自动将GOMAXPROCS与Cgroup CPU Limit对齐,避免了因配置不当导致的常见性能瓶颈(如高延迟、低吞吐)。这将极大简化开发者的运维工作,无需再手动设置GOMAXPROCS或依赖automaxprocs等第三方库。同时,其自动更新机制也使应用能更好地适应K8s等平台的动态资源调整。

当然,该提案并非万能。它主要解决了设置了CPU Limit的场景。对于仅设置CPU Request(旨在利用空闲资源)的Pod,此变更目前不会带来直接改善,GOMAXPROCS仍将基于节点或亲和性设置。如何优化这类场景下的资源利用率,仍是未来值得探索的方向。

总而言之,#73193提案是Go社区直面云原生环境中一个长期痛点的关键举措。它有望将更智能、更自动化的资源感知能力内置到运行时,显著提升Go应用在容器中的默认性能表现和易用性。我们期待该提案的最终落地,并建议开发者关注其后续进展。

你是否也在K8s中遇到过GOMAXPROCS的困扰?欢迎在评论区分享你的经验和看法!

5. 参考资料


Gopher部落知识星球在2025年将继续致力于打造一个高品质的Go语言学习和交流平台。我们将继续提供优质的Go技术文章首发和阅读体验。并且,2025年将在星球首发“Gopher的AI原生应用开发第一课”、“Go陷阱与缺陷”和“Go原理课”专栏!此外,我们还会加强星友之间的交流和互动。欢迎大家踊跃提问,分享心得,讨论技术。我会在第一时间进行解答和交流。我衷心希望Gopher部落可以成为大家学习、进步、交流的港湾。让我相聚在Gopher部落,享受coding的快乐! 欢迎大家踊跃加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格6$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily
  • Gopher Daily Feed订阅 – https://gopherdaily.tonybai.com/feed

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats