
## 先把结论放出来

.NET 10 的 JIT 会做 **object stack allocation**：不逃逸的小对象，`new` 出来直接放栈上，甚至字段被提升进寄存器，一次都不碰 GC 堆。这个特性在 .NET 10 里**默认开启**。

但它有很硬的边界。同一台机器、同一个对象，只改写法，分配量从 0 跳到 24 字节：

| 写法（对象 24 字节） | 每 op 分配 |
| --- | --- |
| `new` 在无循环的小方法里，对象不逃逸 | **0 B** |
| `new` 在 `for` 循环体里（最常见的那种写法） | 24 B |
| `new` 被内联到调用者的循环体里 | 24 B |
| 对象被静态字段持有（逃逸） | 24 B |
| 对象 248 字节以上 | 对象大小 |

换句话说：**它优化的不是「你 new 了」，而是「你在哪儿 new 的」**。

下面所有数字都来自本机实测，不是引用。

## 环境

```
runtime      : 10.0.5
framework    : .NET 10.0.5
os / arch    : macOS 26.7.1 / Arm64
cpu          : Apple M4
serverGC     : False
```

项目配置，`Release` 编译：

```xml
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
  <LangVersion>14</LangVersion>
  <Optimize>true</Optimize>
  <TieredPGO>true</TieredPGO>
</PropertyGroup>
```

## 怎么测才不是自欺欺人

用 `GC.GetAllocatedBytesForCurrentThread()`，只量当前线程，不受别的线程干扰：

```csharp
var b0 = GC.GetAllocatedBytesForCurrentThread();
long acc = 0;
for (var i = 0; i < n; i++) acc += Make(i);
var b1 = GC.GetAllocatedBytesForCurrentThread();
_sink = acc;   // 必须吃掉结果，否则整个循环会被 JIT 当死代码删掉
```

三个坑必须先说清楚，否则下面的数字你复现不出来：

1. **不预热就测，测到的是假的。** 我最早的一版探针没加预热，136 字节的对象测出 136 B/op；加了预热轮次后变成 0。分层编译前面几层不做这个优化，具体是哪一层没生效我没有逐层验证，但「冷启动的数字不能用来下结论」是确定的。
2. **结果必须被使用。** `_sink` 不是装饰。
3. **别用委托调被测方法。** `Func<int,int>` 会挡住内联，把本来能优化的场景测成不能优化，结论直接反掉。每个场景我写独立方法，就是为了躲这个。

## 实验一：不逃逸的 new，真的一字节都不分

```csharp
sealed class Small { public int X; public int Y;
    public Small(int x, int y) { X = x; Y = y; } }

[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
static int MakeSmallNoInline(int i)
{
    var s = new Small(i, i + 1);
    return s.X + s.Y;
}
```

100 万次调用，**分配 0 B**。

光看计数器不够，得看汇编。`DOTNET_JitDisasm=MakeSmallNoInline`：

```asm
G_M000_IG02:
            add     w0, w0, w0
            add     w0, w0, #1
            ldp     fp, lr, [sp], #0x10
            ret     lr
; Total bytes of code 24
```

整个方法 24 字节。没有 `call CORINFO_HELP_NEWSFAST`，没有 `sub sp`，连栈槽都没开——`i + (i+1)` 两次加法就完事。对象头、MethodTable 指针全被优化掉了，字段直接进了寄存器。

这已经不是「栈分配」，是更进一步的标量替换。

## 实验二：一内联，优化立刻失效

把同样的代码内联进循环：

```csharp
static (long, double) BenchSmallInlinable(int n)
{
    // ...
    for (var i = 0; i < n; i++)
    {
        var s = new Small(i, i + 1);   // 这里
        acc += s.X + s.Y;
    }
}
```

实测 **24 B/op**，和 `Small` 对象大小一模一样。

两个版本的差别只有一处：`NEWOBJ` 在不在循环体里。`MakeSmallNoInline` 自己不带循环，JIT 敢把对象完全消掉；一旦内联进调用者的 `for`，对象就老老实实上堆。

这条最反直觉，也最要命——**你为了让代码「更好优化」加 `AggressiveInlining`，结果可能刚好把这个优化干掉了。**

## 实验三：循环体里的 new，从来不管

```csharp
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
static int MakeInnerLoop4(int i)
{
    var acc = 0;
    for (var k = 0; k < 4; k++)
    {
        var s = new Small(i, k);
        acc += s.X + s.Y;
    }
    return acc;
}
```

外层跑 100 万次，结果是 **96 B/op**，正好 4 × 24。四次迭代，四次堆分配，一次都没省。

这条基本判了「热循环里 new 小对象」这个最常见场景的死刑。想省，只能自己池化，或者把循环拆成「每次迭代调用一个不含循环的小方法」——但那通常会把别的优化搭进去，不建议为了省这几个字节去改结构。

## 实验四：尺寸边界在 224 字节和 248 字节之间

同一套测量骨架，只换对象类型，每个类型 4 字节字段递增：

| 对象大小 | 每 op 分配 |
| --- | --- |
| 24 B | 0 B |
| 48 B | 0 B |
| 96 B | 0 B |
| 136 B | 0 B |
| 192 B | 0 B |
| **224 B** | **0 B** |
| **248 B** | **248 B** |
| 512 B | 512 B |
| 1024 B | 1024 B |

224 字节（16 字节对象头 + 208 字节字段）还是零分配，248 字节开始一字节不少地上堆。阈值落在这两个值之间，我没有再往下二分到 8 字节精度——对象布局要 8 字节对齐，剩下的空间很窄，对工程判断没有意义。

但结论够用了：**这就是个「小对象」优化，不是「所有不逃逸对象」优化。**

## 实验五：using 不是元凶，位置才是

一开始我测出 `using` 的对象每 op 分配 24 B，差点写成「`using` 会破坏栈分配」。多做一组对照就打脸了：

| 写法 | 每 op 分配 |
| --- | --- |
| `using` 写在循环体里 | 24 B |
| `using` 写在独立小方法里 | **0 B** |
| 手写 `try/finally` 在独立小方法里 | **0 B** |

`using` 和 `try/finally` 本身完全不影响优化，连 `Dispose()` 调用都被内联掉了。分配的唯一原因还是实验二那条：`using` 所在的位置让 `NEWOBJ` 落进了循环体。

所以别看见分配就去删 `using`。

## 实验六：关掉开关，全部打回原形

```
DOTNET_JitObjectStackAllocation=0
```

再跑一遍，24 B 的场景全部变回 24 B，224 B 的变回 224 B，一个不漏。

这同时证明了两件事：这个优化在 .NET 10 里**默认开启**（环境变量不设也生效），以及前面测到的零分配确实来自它，不是什么测量误差。

## 工程上怎么用

1. **别为了这几个字节重构业务代码。** 这个优化的生效条件太窄，收益只在真正热的路径上才看得见。GC 压力大的地方，先看分配火焰图，再谈优化。
2. **想让它生效，形状要对**：`new` 和「用这个对象」的代码放在同一个不含循环的小方法里，对象不往外传、不存字段、不进闭包。
3. **热循环里 new 的对象，别指望 JIT。** 该上 `ArrayPool<T>`、`ObjectPool<T>` 就上，或者改成 `struct` 从根上避免堆分配。
4. **不要加 `DOTNET_JitObjectStackAllocation=0` 去「求稳定」。** 它只影响分配位置，不改语义；关掉只是让 GC 更忙。

## 复现

```bash
mkdir StackAllocLab && cd StackAllocLab
dotnet new console -f net10.0
# 把上面的 csproj 配置和测量代码填进去
dotnet build -c Release
dotnet bin/Release/net10.0/StackAllocLab.dll

# 对照实验
DOTNET_JitObjectStackAllocation=0 dotnet bin/Release/net10.0/StackAllocLab.dll

# 看汇编
DOTNET_TieredCompilation=0 DOTNET_JitDisasm="MakeSmallNoInline" \
  dotnet bin/Release/net10.0/StackAllocLab.dll
```

最后一句：这套数据在 x64 上我没测。栈分配的阈值和寄存器分配都跟目标架构有关，换平台建议自己重跑一遍再引用。


.NET 10 的 JIT 会做 object stack allocation：不逃逸的小对象，new 出来直接放栈上，甚至字段被提升进寄存器，一次都不碰 GC 堆。这个特性在 .NET 10 里默认开启。

new 出来的对象不一定上堆：.NET 10 JIT 栈分配实测，以及它失效的三条边界

编程语言

开发工具

后端

.NET10 JIT新增对象栈分配优化：不逃逸的小对象（≤224字节）new可直接分配在栈上或提升至寄存器，实现零GC分配。但该优化默认开启且有严格边界——仅在无循环的小方法内生效，热循环内的new仍会产生堆分配。实测显示224字节以下零分配，248字节起恢复堆分配。using语句不影响优化，但方法内联会破坏此优化。

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

new 出来的对象不一定上堆：.NET 10 JIT 栈分配实测，以及它失效的三条边界-腾讯云开发者社区-腾讯云

new 出来的对象不一定上堆：.NET 10 JIT 栈分配实测，以及它失效的三条边界

new 出来的对象不一定上堆：.NET 10 JIT 栈分配实测，以及它失效的三条边界

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐