DEV Community: Pedro Jesus

ArrayPool

Pedro Jesus — Fri, 23 Jan 2026 11:34:15 +0000

Introdução

Pooling é uma estratégia utilizada na programação para reduzir os custos de alocação de certos objetos, que podem ser muito caros para criar e/ou finalizar. Dentro da BCL do .NET existem poucos tipos de pool, sendo os mais famosos o ThreadPool e ArrayPool. Quando usado corretamente, essa estratégia pode ajudar na performance do software; porém, quando usado incorretamente, pode degradar a performance ou deixar o código mais complexo sem alterar o funcionamento do software.

Além dos pools inclusos na BCL do .NET, é possível criar sua própria estratégia de pooling. Caso queira seguir um padrão e não sabe por onde começar, o pacote Microsoft.Extensions.ObjectPool é uma ótima alternativa.

Eu sugiro que você implemente pelo menos um pooling na vida, para ter uma noção. Isso é algo que tem grandes chances de você usar na sua carreira.
Sugiro também, que esse primeiro pooling seja um ArrayPool, depois que fizer e garantir que ele funciona, dê uma olhada na implementação do .NET, ficou muito diferente? Aprendeu algo novo? Implementação.

Esse é mais um artigo que escrevo motivado pela quantidade de baboseiras que vejo na internet, principalmente no LinkedIn, sobre o quanto todas as pessoas que desenvolvem com .NET deveriam usar o ArrayPool em vez de new T[]. Espero que ao final desse artigo você perceba que essa ferramenta não pode ser utilizada em qualquer lugar e das problemáticas existentes em simplesmente sair usando o ArrayPool sem pensar.

Na real, sempre fique com um pé atrás em relação a qualquer "dica" que você veja no LinkedIn.

Usando o ArrayPool

E sem mais delongas vamos ao básico, como usar o ArrayPool?

using System.Buffers;

byte[] buffer = ArrayPool<byte>.Shared.Rent(20);

// Utilizar o array

ArrayPool<byte>Shared.Return(buffer); // Provavelmente você quer isso dentro do finally.

Com isso, poderia-se afirmar: E simples assim, foi obtido um array de bytes com tamanho de 20 para ser utilizado sem alocação real. Como já dizia o poeta, nem tudo que brilha é ouro.

Se você fizer Console.WriteLine(buffer.Length) a saída será 32, ou seja, pedimos por um array de tamanho 20 e recebemos um array de tamanho 32. O motivo para isso é bem simples, o ArrayPool guarda arrays com tamanho de base 2 (2, 4, 8, 16, etc) então ele vai te retornar um array que tenha pelo menos o valor requisitado.

A outra afirmativa, que pode gerar confusão é o "sem alocação real". Existe uma alocação sim, o ArrayPool cria novos arrays sob demanda. Então, se não existir um com o valor desejado, ele será criado e disponibilizado. Se esse array nunca voltar para o pool outro será criado, neste cenário sempre será alocado um novo array. Agora que aprendemos a usar, basicamente, vamos as armadilhas.

Custo de uso de um pool

Como eu disse, nem sempre essa estratégia de pooling é efetiva. Quando o objeto é muito pequeno, é mais barato deixar o GC lidar com isso. Por conta disso o menor array possível de se obter do ArrayPool é de tamanho 16. Com isso, se o cenário precisar de um array menor do que isso é melhor nem usar o ArrayPool, e dependendo de como você usar, o JIT pode otimizar e manter o array na memória stack.

ArrayPool pode te entregar array com lixo

Se o software está rodando há bastante tempo e fazendo uso do ArrayPool, é bem provável que ele te entregue arrays com lixo de memória. Isso acontece pelo fato do ArrayPool não limpar os arrays, por padrão, quando são devolvidos. Além disso, ao alocar novos arrays, eles podem não estar zerados, para ter um ganho de performance. Para ilustrar melhor, olhe o seguinte cenário:

var buffer = ArrayPool<byte>.Shared.Rent(42); // buffer.Length == 64

ProcessMessageFromDevice(buffer); // Vai preencher do índice 0 a 41

foreach(var data in buffer)
{
    SendToController(data); // vai percorrer do índice 0 a 63
}

ArrayPool<byte>.Shared.Return(buffer);

Consegue ver o problema? Exatamente, o foreach vai percorrer todo o array, ou seja, todas as 64 posições. Até o índice 41 é garantido que os dados estarão de acordo com as regras de negocio, mas depois desse índice não existe garantia. Como se resolve isso? Pode-se usar um for ou while, ou manter o foreach e usar o Take(n) do LINQ.

ArrayPool pode causar memory leak

Em alguns casos o uso de ArrayPool pode causar memory leak, a ideia de se ter um pool é manter o(s) objeto(s) vivo(s), isso também é válido para os tipos que eles seguram. Em outras palavras, se o array tiver um ReferenceType ou um ValueType que tenha um ReferenceType isso vai causar um memory leak, se for apenas ValueType não vai ocorrer um leak, no caso dos exemplos aqui ArrayPool<byte> não vai ter esse problema. Agora se for algo do tipo

//ReferenceType
public class Batata
{
}

//ValueType que aponta para um ReferenceType
public struct Banana
{
    public string Value;

    public Banana(string v) => Value = v;
}

var buffer1 = ArrayPool<Batata>.Shared.Rent(42);
var buffer2 = ArrayPool<Banana>.Shared.Rent(42);

for(var i = 0; i < 42; i++)
{
    buffer1[i] = new();
    buffer2[i] = new(i.ToString());
}

ArrayPool<Batata>.Shared.Return(buffer1);
ArrayPool<Banana>.Shared.Return(buffer2);

Nesse caso, quando retornar para o pool o array vai existir e manterá referências fortes para os objetos Batata e Banana, causando assim um memory leak, pois o GC não marcará esses objetos para serem coletados.

No caso da struct, o objeto que vai causar o memory leak é a string.

E como resolver isso? Limpando o array durante a devolução, o método return aceita um bool para indicar se o array deve ser limpo ou não. Para evitar o memory leak basta trocar as duas últimas linhas por:

ArrayPool<Batata>.Shared.Return(buffer1, clearArray: true);
ArrayPool<Banana>.Shared.Return(buffer2, clearArray: true);

Mas vem a pergunta, por que o padrão não é limpar o array sempre ao devolver? Porque fazer essa limpeza pode afetar a performance negativamente ( O(n) ), então por isso os valores não são limpos, e esse gerenciamento fica a cargo de quem os utiliza. Também numa base de código grande isso pode ficar complicado de gerenciar, então se tiver dúvidas ou dependendo do cenário de uso, é possível deixar essa decisão para o runtime, com o método RuntimeHelpers.IsReferenceOrContainsReferences<T>(). Aqui você consegue ver um exemplo de uso, na biblioteca ZLinq.

Não deixar o array sair do escopo

O array obtido pelo ArrayPool não deve sair do escopo do método que está sendo usado. Ou seja, dar um return no array vai tornar ainda mais difícil devolvê-lo, fazendo com que o propósito do pool não seja cumprido.

public int[] Do()
{
    var buffer = ArrayPool<int>.Shared.Rent(16);
    Compute(buffer);
    return buffer; // Como esse array vai ser devolvido?
}

Não fica claro para quem consome o método Do que o array veio de um pool, então, provavelmente, ele não será retornado para o pool.

Não é uma boa prática retornar qualquer array para o pool, se for um array inválido uma exception será lançada.

Agora, se o array não sair do escopo do método é perfeitamente aceitável usá-lo em outros métodos.

// Não usar em prod.
public void ReadMessage(Stream stream)
{
    var buffer = ArrayPool<byte>.Shared.Rent(1024);
    using var memoryStream = new MemoryStream();
    SaveStreamIntoAFile(memoryStream, buffer);

    ArrayPool<byte>.Shared.Return(buffer); // Você certamente vai querer colocar isso no finally
}

Nesse caso, o buffer foi passado para o método SaveStreamIntoAFile e pode ser passado para outros métodos dentro, porém ele nunca vai sair do escopo do ReadMessage, então é garantido que ele poderá ser retornado ao ArrayPool.

Conclusão

A ideia desse artigo é mostrar que ArrayPool não é pra ser usado em todo lugar e pode causar mais problemas do que resolver. A ideia não é desencorajar o uso dessa ferramenta, e sim trazer uma luz aos vários detalhes dessa API, que podem causar problemas no software caso sejam ignorados. Em alguns pontos do seu código vai ser claro quando usar, e quando isso acontecer use. E quando não for claro, profile seu código para ter certeza de que o uso do ArrayPool vai trazer benefícios, mas na dúvida não utilize. Caso queira se aprofundar um pouco mais recomendo esse vídeo do # Stephen Toub sobre ArrayPool.

https://youtu.be/bw7ljmvbrr0

P.S.: Se você está preocupad@ com a possível pressão de memória gerada pelos arrays dentro do ArrayPool, pode ficar tranquil@. Existem algumas políticas de limpeza e uma delas é a pressão de memória, caso haja, o ArrayPool vai remover alguns arrays para serem coletados pelo GC.

Agradeço ao Rafael pela revisão.

Alocações em .NET

Pedro Jesus — Thu, 17 Jul 2025 18:11:20 +0000

Reference Type é alocada na memória heap e Value Type é alocada na memória Stack.

Já adianto que essa afirmativa, acima, está errada!

Se essa afirmativa acima, ou uma variante dela, te parece correta, esse artigo é pra você. Já cansei de ver inúmeros artigos brasileiros (acredito que todos os que vi) sobre gerenciamento de memória fazendo essa afirmativa e, consequentemente espalhando desinformação.

Para Reference Type, é ok considerar que é armazenado na memória heap, até porque é muito sutil quando não é. Agora, é bem comum Value Types serem armazenados fora da memória stack.

Ainda sobre a afirmativa acima. Isso já foi debatido, em 2018, pelo time que trabalha no runtime e na linguagem, você pode ver toda a discussão aqui. Resultando na atualização da documentação oficial para remover tal afirmativa.

Ter esse conceito errado pode não atrapalhar sua carreira agora, principalmente se você for júnior ou até mesmo pleno, porém para os níveis sênior ou master/especialista já é problemático. Uma vez que haverá necessidade de escrever códigos performáticos ou até mesmo investigar/debugar um problema de perfomance. Ter esse modelo de memória equivocado vai te atrapalhar. Sem mais delongas...

Definição

Vamos começar pela definição de cada um desses termos, pela ECMA-335 pode-se dizer (livre tradução):

Value Type: Valores descritos por um tipo de valor são independentes (cada um pode ser compreendido sem referência a outros valores);
Reference Type: Valores do tipo referência representam o endereço de um outro valor, que podem ser de 4 tipos, sendo eles objeto, interface, pointeiro e built-in reference types.

Value Type

Value Types em C# são os tipos representados por struct e quando utilizadas em código são passadas por valor, ou seja, é feita uma cópia do Value Type em questão.
Um exemplo desse comportamento.

int x = 42;
Console.WriteLine(x); // 42
MudarValor(x);
Console.WriteLine(x); // 42


void MudarValor(int x) => x = 69;

Claro que você pode mudar esse comportamento e passar o Value Type por referência, através de um manager pointer. Em C# isso é feito através das keywords ref e in, onde o in indica que o Value Type será passado como um referência readonly.

int x = 42;
Console.WriteLine(x); // 42
MudarValor(ref x);
Console.WriteLine(x); // 69

void MudarValor(ref int x) => x = 69;

Utizando o ref mudou-se o valor de x, pois passou-se uma referência o local de memória e sobrescreveu o valor que estava lá.

Existem algumas limitações para se passar um Value Type por referência. Por exemplo, métodos assíncronos não podem ter parâmetros in ou ref. E essa limitação ocorre pelo simples fato de que, em métodos assíncronos, o ValueType pode ir parar na memória heap!

int x = 42;
Console.WriteLine(x);
MudarValor(ref x);
Console.WriteLine(x);

async void MudarValor(ref int x) => x = 69; // Erro de compilação

Por enquanto vamos ignorar o ref struct, esse tipo terá um capítulo só para ele.

Reference Type

Reference Type em C# são tipos que herdam de System.Object e não herdam de System.ValueType. Esse tipo guarda uma referência para um endereço de memória fazendo com as alterações sejam vista por todos que observam esse valor.

var a = new A() { X = 42 };

Console.WriteLine(a); // 42
MudarValor(a);
Console.WriteLine(a); // 69


void MudarValor(A a) => a.X = 69;

class A
{
    public int X;
    public override string ToString() => X.ToString();
}

No exemplo acima, temos uma classe A e dentro dela um field do tipo int (Value Type), e como você já deve ter "sacado", esse inteiro está na memória heap. Ao passar a para o método MudarValor e alterar o valor X, ele vai alterar o valor naquele espaço de memória, sobrescrevendo o valor que estava antes em X.

Agora, quando se pensa nisso mais a fundo pode ocorrer algumas confusões, por exemplo neste caso.

var a = new A() { X = 42 };

Console.WriteLine(a.X); // 42
MudarValor(a);
Console.WriteLine(a.X); // 42


void MudarValor(A a) => a = null;

class A
{
    public int X;
    public override string ToString() => X.ToString();
}

Ficou confus@ pelo fato do segundo WriteLine ter printado 42 em vez de uma NullReferenceException ter estourado? Se não tiver ficado confus@ pode pular para o próximo capítulo, agora se ficou...

Acontece que quando se passa a para o método, esta se passando uma cópia de um ponteiro (ponteiros no C# funcionam como Value Type), então eu estou anulado a copia dentro método, o ponteiro do método principal continua apontando para o endereço de memória onde A está alocado e com isso não vai ter uma NullReferenceException. Isso pode mudar se a for passado por referência. Por exemplo...

var a = new A() { X = 42 };

Console.WriteLine(a.X); // 42
MudarValor(ref a);
Console.WriteLine(a.X); // NullReferenceException

void MudarValor(ref A a) => a = null;

class A
{
    public int X;
    public override string ToString() => X.ToString();
}

Agora temos a NullReferenceException, e o motivo é que o método MudarValor recebe uma referência de memória de onde está o ponteiro que referência A, e ao marcar como null, dentro do método, aquele espaço na memória será sobrescrito com null, causando a Exception.

Onde eles vivem?

Eu espero, que até aqui tenha ficado claro que Value Type pode viver tanto na memória stack quanto na heap e Reference Type vive na memória heap. Se estiver claro, vamos ir pouco mais fundo...

O local onde esses tipos serão alocados vai depender do contexto em que estão sendo criados e de análises feitas pelo compilador. Se o compilador ver sentido um Value Type pode ser alocado em um CPU register, que é ainda mais rápido que a memória stack, ou seja, em alguns casos o Value Type nem vai viver na memória stack!

Quando ocorrer um boxing o Value Type é alocado na memória heap.

int x = 42; // Não está na heap
object boxing = x; //Está na heap

Mesmo quando ocorre o boxing o comportamento de Value Type se mantém, isto é, ele é passado como cópia quando for utilizado. Você pode ver isso aqui.

E sobre Reference Types, por padrão, estará alocado na memória heap, mas eles também podem ser alocados na memória Stack ou CPU Registers se o compilador perceber que essa classe e seus membros estão limitados ao tempo de vida do método, isso ocorre por algo chamado Escape analysis que você pode ler mais sobre aqui.

Como devo pensar então?

Reference Type é alocada na memória heap e Value Type é alocada na memória Stack.

Acredito que ao chegar aqui essa frase, também, te pareça errada. E deve ter ficado uma pergunta "Então, como devo pensar sobre isso?" e como disse Eric Lippert o melhor jeito a se pensar é short term storage (armazenamento de curto tempo de vida, em tradução livre) e long term storage (armazenamento de longo tempo de vida, em tradução livre). Então, se o objeto (tanto Value Type quanto Reference Type) estiver alocado na heap terá um tempo de vida longo. Se não, terá um tempo de vida curto. Pensar dessa forma torna mais assertiva a investigação de gerenciamento de memória no seu software.

Vale lembrar, que uma struct pode ser alocada inicialmente fora da heap e promovida para heap se tornando long term storage. É muito fácil perceber isso na AsyncStateMachine, que só irá ser alocada na heap se o método marcado com async completar-se de maneira assíncrona, ou seja, o framework irá chamar o método

IAsyncStateMachine.SetStateMachine(IAsyncStateMachine stateMachine);

Fazendo o boxing da struct e movendo-a para a memória heap.

Se quiser olhar mais afundo sobre a relação de métodos marcados com async e o AsyncStateMachine, recomendo o post do Angelo sobre o tema.

Conclusão

Espero que você tenha aprendido, pelo menos, uma coisa nova sobre gerenciamento de memória no .NET e espalhe a palavra. É importante que mais artigos tragam as informações corretas e validadas pelo time que trabalha na linguagem.

Este artigo foi bem simplificado e introdutório, e isso foi proposital, não quis adicionar muita informação aqui e sim dar uma base para que você aprenda o conceito de forma correta e consiga procurar mais referências sobre o tema, os links que deixei espalhado por este artigo são um bom começo.

ref struct (Bônus)

Como prometido, um capítulo apenas para esse tipo especial de Value Type, introduzido no C# 7.2 em 2017. A ref struct é um Value Type que NÃO pode viver na heap. Ela tem um tempo de vida curto e não pode escapar do contexto do método em que foi criada, com isso ela tem uma série de limitações, garantidas pelo compilador, mas no fim das contas é apenas uma struct, como pode ser visto nesse lowering.

Esse tipo é utilizado, especialmente, em algoritmos de alta performance. A garantia de que ela não vai vazar para a heap, e por isso não será gerenciada pelo Garbage Collector, e por isso o endereço desses objetos são determinísticos, ou seja, uma vez alocado ele não mudará, logo não é necessário fazer verificações para ver se o objeto ainda está no mesmo endereço.

Porém, não caia na armadilha de achar que Value Type é sempre mais performático que Reference Type. Antes de refatorar seu código, baseado em um post duvidoso do Linkedin (praticamente todos os posts sobre benchmark ou gerenciamento de memória são duvidosos), faça medições para ter certeza que a mudança trará ganhos!

Finalizo a parte bônus com essa imagem e recomendando a palestra ministrada pelo Andy no .NET Conf 2024, New Features in the .NET 9 JIT.

.NET: Brincando com ref structs

Pedro Jesus — Wed, 03 Apr 2024 20:49:26 +0000

Dias atrás, resolvi brincar com ref structs, fazendo alguns experimentos e pensando em como reduzir o boilerplate de usar try/finally para trocar o valor de uma variável Booleana. Foi um processo divertido. Como vejo pouco conteúdo sobre ref structs, em pt-BR, resolvi compartilhá-lo aqui. Acredito que vai ficar um pouco grande, pois vou falar sobre vários aspectos que fiz e alguns problemas e soluções. Irei separar em subtítulos para facilitar a leitura.

O código apresentado aqui é bem simples. Caso queira usá-lo em produção, sugiro adicionar alguns testes unitários para garantir o perfeito funcionamento.
E O MAIS IMPORTATE, conte-me como foi!

1. O Problema

Diversas vezes, me vi escrevendo códigos que precisam de um valor Booleano para saber se a lógica deve ser executada ou não. Usualmente, algo assim:

class ViewModel
{
    private bool flag;

    void SomeCode()
    {
        if (flag)
            return;

        flag = true;
        try
        {
            // Código omitido...
        }
        finally
        {
            flag = false;
        }
    }
}

Imagine que teria de utilizar essa flag em vários lugares, métodos dentro dessa classe ou até esse mesmo padrão em outros lugares... Não gostaria de ter que ficar reescrevendo essa estrutura do try/finally, pois ela é bem extensa. Quero uma solução que eliminará esse boilerplate e garantirá que não impactará a performance da aplicação. Se você já está mais familiarizado com performance, sabe que o ideal é evitar que existam alocações na memória heap. E para garantir isso vou precisar de usar ref struct (não confundir com struct).

Mesmo que struct seja um ValueType, isso não é garantia que ela estará na memória stack. Com isso, aquela afirmação de que "ValueType vive na stack e ReferenceType vive na heap" é um equivoco enorme!
Existem muito mais nuances, eis aqui uma discussão do time que escreve a linguagem e o runtime sobre esse tema, vale a pena a leitura.
Apenas um exemplo: para provar meu ponto, uma List<int> terá seus valores, que são inteiros (ValueTypes), alocados na memória heap.

2. Começando a solucionar o problema

Então, como dito anteriormente, quero garantir que a solução viva na memória stack, tendo o mínimo de impacto na performance da aplicação - tenhamos isso em mente. Antes de começar a implementar uma API, EU gosto de pensar em como gostaria de consumir esse código. Com isso definido, fica mais fácil trabalhar na implementação. Claro que pode haver mudanças durante o processo por conta de alguma limitação. Então, abaixo está o código que eu desejo escrever:

class ViewModel
{
    private bool flag;

    void SomeCode_Jeito1()
    {
        if (flag)
            return;

        using var _ = new MyRefStruct(ref flag, valueToSet: true);

        // Resto da lógica
    }

    void SomeCode_Jeito2()
    {
        if (flag)
            return;

        using(new MyRefStruct(ref flag, valueToSet: true))
        {
            // Resto da lógica
        }
        // Outra lógica
    }
}

Por padrão, todo ValueType é passado como cópia. Para garantir que a mudança de valor dentro de MyRefStruct seja propagada para o flag dentro da classe ViewModel, ele deve ser passado por referência.
Eu quero "setar" o valor da flag para true quando for começar a lógica, por isso adiciono o segundo parâmetro no construtor.
O using garantirá que tudo entre using var _ ... e o último } do método SomeCode_Jeito1 ficará dentro de um try/finally e chamará o método Dispose dentro de MyRefStruct. Como você deve ter imaginado, dentro do Dispose mudaremos o valor de flag para false. No caso do método SomeCode_Jeito2, tudo que estiver entre as {} do using ficará dentro de um try/finally.

Aproveitando, adivinhe onde a variável flag ficará alocada? Não é na memória stack 😉.

Essa abordagem me deixa bem contente. Afinal, troquei todo aquele boilerplate por apenas 1 linha. Com esses itens em mente, criaremos nossa ref struct.

3. Criando a ref struct

Você já deve saber que para usar o using eu preciso de implementar a interface IDisposable. É uma interface bem simples, que tem apenas um método na sua definição void Dispose(). Então, teríamos algo desse tipo:

ref struct HoldAndChangeValue : IDisposable {}

Mas, isso não compilará! Por quê?! Bom, quando uma struct implementa uma interface, ela pode ser alocada na memória heap, por meio do boxing. E como ref structs NÃO podem ser alocadas na heap, de jeito nenhum, o compilador não permite que ela implemente interfaces.

Sim, meu jovem Padawan, eu sabia dessa limitação, mas quis pregar uma peça em você. Consegui? Bom, se sim, agora, vou te ensinar algo bem bacana.

"Para nossa alegria", várias funcionalidades da linguagem C# são baseadas em duck type. Logo, eu só preciso ter o método public void Dispose(){} definido no meu tipo e, voilà, podemos usá-lo. Para os outros tipos (class, struct etc), é necessário implementar a interface IDisposable.
Algumas funcionalidades do C# utilizam o duck type , como: foreach, async/await etc. Inclusive, eis aqui um exemplo de como fazer com que isto: await 42;, seja válido.

Baseado nas informações dos parágrafos anteriores e em como queremos usar em código, nossa HoldAndChangeValue ficará:

ref struct HoldAndChangeValue
{
    ref bool value;

    public HoldAndChangeValue(ref bool flag, bool valueToSet)
    {
        value = ref flag;
        value = valueToSet;
    }

    public void Dispose()
    {
        value = !value;
    }
}

E é isso! O código fica mais simples de escrever e o funcionamento é como esperado. Fique a vontade para verificar aqui.

No link acima, tente implementar a estrutura do método SomeCode_Jeito2. Você perceberá que dentro das chaves o valor da flag será True e fora voltará para False.

Acredito que vale a pena reforçar, que a ref struct possui diversas limitações de uso. Isso serve para garantir que ela não seja alocada na memória heap. Então, essa solução não funcionará em métodos que têm o modificador async, dentro de uma lambda expression que capture essa ref struct em uma closure, dentre outros cenários.

4. Expandindo nossa ref struct

A solução proposta no capítulo anterior resolve boa parte dos cenários. Porém, não lida com propriedades. Para quem usa o padrão MVVM, por exemplo, seria muito interessante ter suporte a propriedades. Acredito que já tenha visto a estrutura do IsBusy. Caso não conheça, é semelhante ao exemplo que usei. Contudo, em vez de usar um field utiliza-se uma propriedade.
O maior problema é que não se pode passar propriedades como referência. Isso se deve ao fato de que propriedades, no C#, são um sugar syntax para métodos (getter & setter).
É possível ver isso aqui. Dentro do IL (Intermediated Language), você verá que não há um valor para essa propriedade, como há para o field, mas métodos de get & set.

E qual a solução? Pelo que pesquisei e experimentei, isso só pode ser feito usando delegates. Nesse caso, usei uma Action. Só que Action, assim como delegates, são ReferenceTypes. Logo, são alocados por padrão, na memória heap... E agora?

Inclusive, se você souber outra maneira de copiar o comportamento do ref com propriedades, conte-me, estou muito interessado!

Agora, é só adicionar uma Action como parâmetro no construtor da ref struct e criar uma variável local para isso e vida que segue... Mas, espere aí... Como colocarei algo que é alocado na heap dentro de algo que não pode ser? Bom, se você conseguiu ler e entender a discussão que fiz referência no começo do artigo, sobre onde se alocam ValueType & ReferenceType, ficará mais claro.

Digo "conseguiu ler e entender", acima, pois toda a discussão está em inglês e eu sei que nem todo mundo tem proficiência nessa linguagem, em um país como o nosso é completamente aceitável esse cenário. Particularmente, EU digo que é muito importante praticar o inglês se quiser se tornar um(a) profissional melhor. De todo modo, acredito que as ferramentas que traduzem sites estejam bem melhores atualmente. Usem-nas sempre que possível. Mas, logo abaixo, eu explico melhor o "Eureka" desse caso em particular.

Continuando... Sim, nossa ref struct NÃO viverá na memória heap, mas ela pode referenciar objetos que viverão. Isso porque o tempo de vida desses objetos serão maiores do que o tempo de vida de nossa ref struct. Quando passarmos a Action para nossa ref struct, o que passaremos, na verdade, é o endereço de memória dessa Action, o qual fica na memória stack. Logo, ele pode viver tranquilamente na nossa ref struct. Para uma visualização gráfica do que estou falando, acesse aqui.

Com isso, veremos, primeiramente, como eu gostaria de consumir o código e, então, implementaremos a solução.

class ViewModel
{
    public bool IsBusy {get; set;} = false;
    public void Run()
    {
        if (IsBusy)
        return;

        IsBusy = true;
        using var _ = new HoldAndChangeValueProperty(() => IsBusy = !IsBusy);

        // Código a ser executado   
    }
}

Deixo para você remover a linha IsBusy = true; e a abstrair dentro da ref struct.

A implementação, nesse caso, será bem simples também. Basta apenas passar a Action para a ref struct e a executar dentro do método Dispose.

ref struct HoldAndChangeValueProperty
{
    Action propAction;

    public HoldAndChangeValue(Action action)
    {
        propAction = action;
    }

    public void Dispose()
    {
        propAction();
    }
}

Para ver o código em execução, basta acessar aqui.

Para dar suporte ao uso de propriedades, a solução, como um todo, tocará na memória heap, pois precisaremos de uma Action para fazê-lo funcionar corretamente. Alocando uma única Action é algo tranquilo, pois o tamanho será de apenas alguns bytes. O problema é se isso for um trecho de código muito executado, daí pode ser necessário verificar o impacto de performance. E é exatamente isso que vou falar no próximo capítulo.

5. Alocações implícitas (Implicit Allocations)

Basicamente, alocações implícitas são quando algo vai ser armazenado na memória heap, mas sem que isso seja mostrado diretamente. Por exemplo, var obj = new object();, essa chamada está alocando um novo objeto na memória heap. Isso é explicito, pois estamos instanciando esse objeto com o uso da keyword new.
Agora, object i = 10; é uma alocação implícita, por meio de boxing. Estou convertendo o inteiro 10 em um ReferenceType, que será armazenado na memória heap. Se quiser aprofundar no tema, recomendo este artigo do Stephen Toub.

No nosso caso, onde acontece essa alocação? Ela ocorre quando passamos a Action para a ref struct. Se observamos o que o compilador gera pelo código, você verá que o compilador reescreve boa parte do nosso código, mas a principal, nesse cenário, é esta linha:

// O que escrevemos
using var _ = new HoldAndChangeValueProperty(() => IsBusy = !IsBusy);

Será reescrita em:

// Como o compilador reescreve
HoldAndChangeValueProperty holdAndChangeValueProperty = new HoldAndChangeValueProperty(new Action(<Run>b__4_0));

Onde o <Run>b__4_0 é um método gerado pelo compilador. Olhando essa linha, é possível perceber que toda vez que esse método é executado, será alocada uma nova Action, que executará o mesmo método... Isso é bem ineficiente, afinal se o método é o mesmo por que não fazer um cache?

Você já deve ter ouvido/lido a seguinte frase "compiladores são burros". Se não ouviu, acredito que ouvirá/lerá em algum momento da jornada como pessoa desenvolvedora. Eu concordei com essa frase por muito tempo. Agora, eu penso de outra maneira. Eu diria que os compiladores são conservadores, eles preferem, por padrão, garantir o funcionamento correto em vez de otimizações.

Como, por padrão, compiladores preferem garantir estabilidade em vez de otimizações. Esse tipo de cenário é bem comum em vários pontos de qualquer linguagem.

5.1 Entendendo e solucionado o problema

Vamos criar um cenário em que esse trecho de código será executado 10 mil vezes. O que você acha que ocorrerá? Exato, serão alocadas 10 mil Actions para fazer exatamente a mesma coisa. Para comprovar, criei um código de teste. O método que será utilizado para analisar as alocações é este:

    public void Run()
    {
        for (var i = 0; i < 10_000; i++)
        {
            viewModel.Run();
            if (i is 5_000)
            {
                Console.ReadLine();
            }
        }
    }

Ao final da execução, eis os resultados:

Como podemos ver a classe ViewModel no método Run, alocou 10 mil Actions, como eu havia dito. Para mim, esse comportamento é inaceitável. Mas, ele é um problema que está fora do escopo da nossa ref struct, pois quem cria essas alocações é o compilador. Para resolver isso, devemos criar, manualmente, o cache dessa Action e usá-la. Refatorando o código da ViewModel, teremos:

class ViewModel
{
    public bool IsBusy { get; set; } = false;

    readonly Action updateIsBusy;

    public ViewModel()
    {
        updateIsBusy = () => IsBusy = !IsBusy;
    }

    public void Run()
    {
        using (new HoldAndChangeValue(updateIsBusy))
        {
            // Código a ser executado
        }
    }
}

Com essa mudança, o código gerado pelo compilador será:

HoldAndChangeValueProperty holdAndChangeValueProperty = new HoldAndChangeValueProperty(updateIsBusy);

Como podemos ver, não existe mais uma nova alocação toda vez que o método Run rodar. Para comprovar, utilizaremos o mesmo código de testes nessa nova versão da classe ViewModel. Os resultados podem ser vistos na imagem abaixo:

Como pode ser observado, apenas uma Action foi instanciada e será utilizada em todas as chamadas do método ViewModel.Run.

6. Conclusão

Concluímos nossa aventura pela ref struct. Como você deve ter notado, existe bastante coisa para se entender além da ref struct por si só. Espero que as referências, aqui citadas, possam te ajudar nessa jornada e agregar ainda mais conhecimento.

Não tenha medo de utilizar ref structs. É um recurso novo na linguagem, bem nichado também, mas vale a pena se familiarizar com ele e outros recursos. Afinal, eles permitem que possamos escrever códigos performáticos sem precisar de usar unsafe.

Por favor, conte-me suas aventuras com ref struct. Estou muito interessado no que você criará!