Ile miejsca zajmuje int w C#? 4 bajty, zakres i wybór typu

Gdy aplikacja zaczyna przechowywać duże identyfikatory, liczniki albo rozmiary plików, szybko pojawia się pytanie, ile miejsca naprawdę zajmuje typ int. W C# odpowiedź jest prosta, ale ma kilka ważnych wyjątków: zwykły int ma zawsze 32 bity, natomiast jego rzeczywisty wpływ na pamięć zależy od tego, czy znajduje się w tablicy, obiekcie, czy został opakowany jako object. Pokażę też, jak sprawdzić rozmiar w kodzie i kiedy lepiej wybrać long albo nint.

Ile pamięci zajmuje int w C#

W języku C# słowo kluczowe int jest aliasem dla typu System.Int32. Jego rozmiar wynosi zawsze 32 bity, czyli 4 bajty, niezależnie od tego, czy aplikacja działa na Windowsie, Linuksie, procesorze x64 czy ARM64.

32 bity nie oznaczają 32 bitów przeznaczonych wyłącznie na dodatnie liczby. Jeden bit przechowuje znak, dlatego typ podpisany może przechowywać zarówno wartości ujemne, jak i dodatnie. Taki zakres wystarcza dla większości liczników, indeksów kolekcji i identyfikatorów używanych w typowych aplikacjach biznesowych.

Czy system 64-bitowy zmienia rozmiar int

Nie. To częste nieporozumienie wynikające z mieszania int z typami wskaźnikowymi. W aplikacji 64-bitowej referencje i wskaźniki zajmują zwykle 8 bajtów, ale int nadal zajmuje 4 bajty.

Ma to praktyczne znaczenie przy projektowaniu tablic i struktur danych. Przejście procesu z 32 na 64 bity nie podwaja automatycznie pamięci używanej przez tablicę int[], choć narzut samego obiektu lub innych pól może się zmienić.

Jak sprawdzić rozmiar int w kodzie

Najprościej użyć operatora sizeof. Dla wbudowanych typów prostych, takich jak int, nie trzeba włączać kontekstu unsafe.

Console.WriteLine(sizeof(int));       // 4
Console.WriteLine(sizeof(int) * 8);   // 32

Console.WriteLine(int.MinValue);      // -2147483648
Console.WriteLine(int.MaxValue);      // 2147483647

Wartość zwracana przez sizeof(int) opisuje rozmiar samej wartości. Nie mówi jeszcze, ile pamięci zajmie obiekt, w którym ta wartość się znajduje. To rozróżnienie jest ważniejsze niż sama liczba 4, szczególnie przy optymalizacji dużych kolekcji.

Można też sprawdzić reprezentowany typ systemowy. Poniższy kod pokaże, że int i System.Int32 są tym samym typem.

Console.WriteLine(typeof(int) == typeof(System.Int32)); // True
Console.WriteLine(System.Runtime.InteropServices.Marshal.SizeOf()); // 4

Do zwykłej diagnostyki używam przede wszystkim sizeof(int). Jest czytelne, nie wymaga refleksji i dokładnie odpowiada na pytanie o rozmiar reprezentacji liczby.

Zakres wartości jest równie ważny jak liczba bajtów

Cztery bajty dają 2³² różnych kombinacji bitów, ale typ int jest podpisany. W praktyce największa dodatnia wartość to 2 147 483 647, więc licznik może przepełnić się szybciej, niż sugeruje sam rozmiar typu.

Przepełnienie oznacza, że wynik nie mieści się w zakresie docelowego typu. W kontekście unchecked, który jest typowy dla zwykłych operacji całkowitoliczbowych, przekroczenie maksymalnej wartości może zawinąć się do wartości ujemnej.

int value = int.MaxValue;
int result = value + 1;

Console.WriteLine(result); // -2147483648

Jeśli takie zachowanie byłoby błędem, używam bloku checked. Wtedy program zgłosi OverflowException, zamiast po cichu zapisać nieprawidłowy wynik.

int value = int.MaxValue;

try
{
    int result = checked(value + 1);
}
catch (OverflowException)
{
    Console.WriteLine("Przekroczono zakres typu int.");
}

W systemach finansowych, raportowych i przetwarzających duże pliki nie zakładam, że int wystarczy tylko dlatego, że wartości są obecnie niewielkie. Typ powinien wynikać z maksymalnego możliwego zakresu, a nie wyłącznie z danych testowych.

Int, long i nint nie rozwiązują tego samego problemu

Wybór typu warto oprzeć na tym, co reprezentuje liczba. long ma stały rozmiar 8 bajtów, natomiast nint dopasowuje się do architektury procesu. To nie są zamienniki używane według uznania.

Typ nint zajmuje 4 bajty w procesie 32-bitowym i 8 bajtów w procesie 64-bitowym. Przydaje się głównie przy kodzie natywnym, wskaźnikach i interop, czyli komunikacji z bibliotekami spoza środowiska .NET.

W codziennym kodzie aplikacyjnym zazwyczaj wybieram int albo long. Użycie nint tylko dlatego, że aplikacja działa na komputerze 64-bitowym, zwykle komplikuje kod i nie daje realnej korzyści.

Cztery bajty wartości nie oznaczają czterech bajtów obiektu

Najprostszy przypadek to pojedyncza zmienna typu int. Gdy jednak liczba jest częścią obiektu, tablicy albo została opakowana jako object, dochodzą informacje zarządzane przez środowisko uruchomieniowe .NET.

Tablica int

W tablicy int[] każda wartość zajmuje zwykle 4 bajty. Tablica o długości 1 000 000 potrzebuje więc około 4 MB na same elementy, ale całkowity rozmiar będzie większy przez nagłówek obiektu i wyrównanie pamięci.

int[] values = new int[1_000_000];
// około 4 000 000 bajtów na elementy
// plus narzut obiektu tablicy

To właśnie dlatego przy dużych kolekcjach zwracam uwagę nie tylko na typ elementów, lecz także na liczbę obiektów i sposób przechowywania danych. Jedna duża tablica bywa znacznie oszczędniejsza niż wiele małych obiektów zawierających po jednej liczbie.

Przeczytaj również: Pętla do-while w C# - składnia, przykłady i pułapki

Int jako pole klasy i boxing

Jeżeli klasa ma pole typu int, pole wnosi do jej układu 4 bajty wartości, ale cała instancja ma jeszcze nagłówek obiektu oraz ewentualne inne pola. Nie można więc obliczać rozmiaru obiektu przez zwykłe zsumowanie samych typów bez uwzględnienia układu pamięci.

Jeszcze większy narzut pojawia się podczas boxingu, czyli zamiany typu wartościowego na object lub interfejs. Opakowany int nadal przechowuje 4-bajtową liczbę, ale otrzymuje również nagłówek obiektu i podlega alokacji na stercie.

int number = 42;
object boxed = number;

W kodzie wykonywanym w pętli takie niepozorne konwersje mogą tworzyć dużo krótkotrwałych obiektów i zwiększać pracę garbage collectora. Sam rozmiar int jest mały, lecz sposób użycia potrafi mieć zauważalny wpływ na wydajność.

Jak dobrać typ do praktycznego zastosowania

Dla indeksu kolekcji, liczby elementów na stronie czy kodu statusu int jest zwykle najlepszym wyborem. Jest wystarczająco duży, dobrze wspierany przez biblioteki .NET i nie zajmuje niepotrzebnych 8 bajtów.

• Wybierz int dla wartości, które pozostaną poniżej 2 147 483 648.
• Wybierz long, gdy liczba może przekroczyć zakres int albo pochodzi z API używającego 64-bitowych identyfikatorów.
• Wybierz nint tylko wtedy, gdy rozmiar liczby ma odpowiadać rozmiarowi wskaźnika procesu.
• Nie używaj uint wyłącznie po to, aby uzyskać większą dodatnią wartość. Ujemne liczby, konwersje i zgodność z bibliotekami mogą wtedy stać się mniej wygodne.
• Dla rozmiarów plików stosuj long, ponieważ wartość wyrażona w bajtach może szybko przekroczyć zakres int.

Przy projektowaniu kontraktu API patrzę nie tylko na dzisiejsze dane, lecz także na kompatybilność i przyszły rozwój systemu. Zmiana typu z int na long może później wymagać migracji bazy danych, zmian serializacji i aktualizacji klientów, więc lepiej przewidzieć realny zakres na początku.

Najprostsza reguła wyboru typu całkowitego

Jeżeli pytasz wyłącznie o rozmiar, odpowiedź brzmi 4 bajty i 32 bity. Jeśli pytasz o pamięć całej struktury, sprawdź także narzut obiektów, tablic, wyrównanie i ewentualny boxing.

W typowej aplikacji .NET zacząłbym od int, przy dużych zakresach wybrałbym long, a po nint sięgnąłbym dopiero wtedy, gdy kod rzeczywiście współpracuje z natywną architekturą procesu. Taki wybór jest czytelny, przewidywalny i zwykle daje najlepszy kompromis między zakresem wartości a zużyciem pamięci.