\n Modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131ndan biri olan bellek y\u00f6netimi, uygulamalar\u0131n performans\u0131 ve kararl\u0131l\u0131\u011f\u0131 \u00fczerinde do\u011frudan bir etkiye sahiptir. .NET platformu, geli\u015ftiricilerin bu karma\u015f\u0131k g\u00f6revin y\u00fck\u00fcn\u00fc hafifletmek i\u00e7in g\u00fc\u00e7l\u00fc bir \u00c7\u00f6p Toplama (Garbage Collection – GC) mekanizmas\u0131 sunar. Bu makale, .NET GC’nin derinliklerine inerek nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, farkl\u0131 jenerasyonlar\u0131n\u0131, tetikleyicilerini ve performans \u00fczerindeki etkilerini detayl\u0131 bir \u015fekilde a\u00e7\u0131klayacakt\u0131r. Ayr\u0131ca, GC’nin ne zaman kritik bir \u00f6neme sahip oldu\u011funu ve uygulamalar\u0131n\u0131zda en iyi performans\u0131 elde etmek i\u00e7in nelere dikkat etmeniz gerekti\u011fini pratik \u00f6rnekler ve ipu\u00e7lar\u0131yla ele alaca\u011f\u0131z.\n<\/p>\n
\n Yaz\u0131l\u0131m geli\u015ftirme tarihinde, bellek y\u00f6netimi her zaman \u00f6nemli ve hata yapmaya a\u00e7\u0131k bir alan olmu\u015ftur. Geli\u015ftiricilerin manuel olarak bellek tahsis etmesi ve serbest b\u0131rakmas\u0131 gereken dillerde (\u00f6rne\u011fin C++), bellek s\u0131z\u0131nt\u0131lar\u0131 (memory leaks), ask\u0131da kalan i\u015faret\u00e7iler (dangling pointers) ve \u00e7ift serbest b\u0131rakma (double free) gibi yayg\u0131n sorunlar uygulamalar\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 ciddi \u015fekilde tehdit edebilirdi. .NET’in \u00c7\u00f6p Toplay\u0131c\u0131s\u0131, bu zorluklar\u0131 ortadan kald\u0131rarak geli\u015ftiricilerin daha \u00e7ok i\u015f mant\u0131\u011f\u0131na odaklanmas\u0131n\u0131 sa\u011flar.\n<\/p>\n
\n Y\u00f6netilmeyen dillerde, bir nesne olu\u015fturuldu\u011funda bellekten yer ayr\u0131lmas\u0131 ve i\u015fi bitti\u011finde bu yerin geri verilmesi tamamen geli\u015ftiricinin sorumlulu\u011fundad\u0131r. Bu durum, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k projelerde, hatalara ve performans sorunlar\u0131na yol a\u00e7an yayg\u0131n bir kaynakt\u0131r. .NET gibi y\u00f6netilen ortamlarda ise, bu sorumlulu\u011fun b\u00fcy\u00fck bir k\u0131sm\u0131 \u00e7al\u0131\u015fma zaman\u0131na (runtime) devredilir.\n<\/p>\n
\n .NET’in ortak dil \u00e7al\u0131\u015fma zaman\u0131 (Common Language Runtime – CLR), uygulamalar\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in bir “y\u00f6netilen y\u0131\u011f\u0131n” (managed heap) sa\u011flar. T\u00fcm referans tipli nesneler (class instances, arrays vb.) bu y\u0131\u011f\u0131nda olu\u015fturulur. GC, bu y\u0131\u011f\u0131n\u0131 s\u00fcrekli olarak izler ve art\u0131k uygulama taraf\u0131ndan eri\u015filemeyen (yani “\u00e7\u00f6p” haline gelmi\u015f) nesneleri otomatik olarak tespit edip bellekten kald\u0131r\u0131r. Bu, bellek g\u00fcvenli\u011fini art\u0131r\u0131r ve bellekle ilgili hatalar\u0131n \u00e7o\u011funu engeller.\n<\/p>\n
\n GC’nin temel amac\u0131 iki y\u00f6nl\u00fcd\u00fcr:<\/p>\n
\n .NET GC, sofistike bir algoritma kullanarak \u00e7al\u0131\u015f\u0131r. Temel olarak, bir nesnenin canl\u0131 olup olmad\u0131\u011f\u0131n\u0131 belirlemek i\u00e7in “ula\u015f\u0131labilirlik” prensibini kullan\u0131r. E\u011fer bir nesneye uygulaman\u0131n k\u00f6klerinden (\u00f6rne\u011fin statik alanlar, y\u0131\u011f\u0131n de\u011fi\u015fkenleri, CPU registerlar\u0131) do\u011frudan veya dolayl\u0131 olarak ula\u015f\u0131labiliyorsa, o nesne canl\u0131 kabul edilir. Aksi takdirde, \u00e7\u00f6p olarak i\u015faretlenir.\n<\/p>\n
\n Bir nesnenin \u00f6mr\u00fc, olu\u015fturuldu\u011fu andan itibaren ba\u015flar ve art\u0131k hi\u00e7bir k\u00f6kten eri\u015filemez hale geldi\u011fi ana kadar devam eder. GC, bir toplama d\u00f6ng\u00fcs\u00fc ba\u015flatt\u0131\u011f\u0131nda, ilk olarak t\u00fcm k\u00f6kleri belirler ve bu k\u00f6klerden eri\u015filebilen t\u00fcm nesneleri i\u015faretler. Bu i\u015flem, genellikle bir grafik ge\u00e7i\u015fi (graph traversal) \u015feklinde ger\u00e7ekle\u015fir.\n<\/p>\n
\n .NET GC, temel olarak “i\u015faretle ve s\u0131k\u0131\u015ft\u0131r” (mark and compact) algoritmas\u0131n\u0131n bir varyasyonunu kullan\u0131r:<\/p>\n
\n Kompaktlama i\u015flemi, GC’nin \u00f6nemli bir \u00f6zelli\u011fidir. Nesnelerin ta\u015f\u0131nmas\u0131, referanslar\u0131n\u0131n g\u00fcncellenmesini gerektirir. CLR, bu referans g\u00fcncellemelerini otomatik olarak y\u00f6netir. Kompaktlama sayesinde, yeni nesne tahsisleri \u00e7ok h\u0131zl\u0131 bir \u015fekilde, genellikle i\u015faret\u00e7i art\u0131rma (pointer increment) y\u00f6ntemiyle yap\u0131labilir, \u00e7\u00fcnk\u00fc her zaman y\u0131\u011f\u0131n\u0131n sonunda bo\u015f ve biti\u015fik bir alan bulunur.\n<\/p>\n
\n T\u00fcm nesneleri her GC d\u00f6ng\u00fcs\u00fcnde taramak, \u00f6zellikle b\u00fcy\u00fck uygulamalarda \u00e7ok maliyetli olabilir. .NET GC, bu sorunu \u00e7\u00f6zmek i\u00e7in “jenerasyonel” (generational) bir yakla\u015f\u0131m benimser. Bu yakla\u015f\u0131m, nesnelerin \u00f6m\u00fcrlerinin farkl\u0131 oldu\u011funu varsayar: \u00e7o\u011fu nesne k\u0131sa \u00f6m\u00fcrl\u00fcd\u00fcr (ge\u00e7ici de\u011fi\u015fkenler), baz\u0131lar\u0131 orta \u00f6m\u00fcrl\u00fcd\u00fcr (\u00f6nbellekler), \u00e7ok az\u0131 ise uygulaman\u0131n t\u00fcm \u00f6mr\u00fc boyunca ya\u015far (singletonlar). GC, bu varsay\u0131ma dayanarak y\u0131\u011f\u0131n\u0131 jenerasyonlara ay\u0131r\u0131r.\n<\/p>\n
\n .NET’te \u00fc\u00e7 ana jenerasyon bulunur: Jenerasyon 0 (Gen 0), Jenerasyon 1 (Gen 1) ve Jenerasyon 2 (Gen 2).\n<\/p>\n
\n Yeni olu\u015fturulan t\u00fcm nesneler Jenerasyon 0’a yerle\u015ftirilir. Gen 0, en s\u0131k toplanan jenerasyondur ve genellikle \u00e7ok h\u0131zl\u0131 bir \u015fekilde tamamlan\u0131r. K\u00fc\u00e7\u00fck bir bellek alan\u0131 kaplar. Bir Gen 0 toplamas\u0131ndan sonra hala canl\u0131 kalan nesneler Jenerasyon 1’e y\u00fckseltilir.\n<\/p>\n
\n Jenerasyon 1, Gen 0’dan hayatta kalan nesneleri i\u00e7erir. Gen 0’a g\u00f6re daha az s\u0131kl\u0131kla toplan\u0131r ve daha b\u00fcy\u00fck bir bellek alan\u0131na sahiptir. Bir Gen 1 toplamas\u0131ndan sonra hala canl\u0131 kalan nesneler Jenerasyon 2’ye y\u00fckseltilir. Gen 1, asl\u0131nda k\u0131sa \u00f6m\u00fcrl\u00fc nesnelerin Gen 2’ye ula\u015fmas\u0131n\u0131 engellemek i\u00e7in bir ara tampon g\u00f6revi g\u00f6r\u00fcr.\n<\/p>\n
\n Jenerasyon 2, en uzun \u00f6m\u00fcrl\u00fc nesneleri i\u00e7erir. Gen 1’den hayatta kalan nesneler ve do\u011frudan Gen 2’ye tahsis edilen b\u00fcy\u00fck nesneler burada bulunur. Gen 2, en az s\u0131kl\u0131kla toplan\u0131r ve t\u00fcm y\u00f6netilen y\u0131\u011f\u0131n\u0131 kapsar. Gen 2 toplamalar\u0131 en maliyetli olanlard\u0131r ve uygulaman\u0131n duraklamas\u0131na (pause) neden olabilir.\n<\/p>\n
\n 85 KB’den b\u00fcy\u00fck nesneler (\u00f6rne\u011fin b\u00fcy\u00fck diziler veya string’ler) do\u011frudan B\u00fcy\u00fck Nesne Y\u0131\u011f\u0131n\u0131’na (LOH) tahsis edilir. LOH, Jenerasyon 2’nin bir par\u00e7as\u0131 olarak kabul edilir ancak farkl\u0131 bir \u015fekilde y\u00f6netilir. LOH’taki nesneler ta\u015f\u0131nmaz (kompaktlanmaz). Bunun nedeni, b\u00fcy\u00fck nesnelerin ta\u015f\u0131nmas\u0131n\u0131n \u00e7ok maliyetli olmas\u0131d\u0131r. LOH’taki par\u00e7alanma (fragmentation) bir sorun olabilir ve performans\u0131 etkileyebilir.\n<\/p>\n
\n Jenerasyonlar\u0131n \u00d6zeti:<\/strong>\n<\/p>\n \n GC, belirli ko\u015fullar alt\u0131nda otomatik olarak tetiklenir. Ancak, geli\u015ftiriciler de nadiren manuel olarak tetikleyebilirler. GC’nin \u00e7al\u0131\u015fma \u015fekli, uygulama t\u00fcr\u00fcne g\u00f6re de farkl\u0131l\u0131k g\u00f6sterebilir.\n<\/p>\n \n GC, a\u015fa\u011f\u0131daki durumlarda otomatik olarak bir toplama i\u015flemi ba\u015flat\u0131r:<\/p>\n \n Geli\u015ftiriciler, <\/code><\/p>\n \n .NET, iki ana GC modu sunar:<\/p>\n Bu modlar, uygulaman\u0131z\u0131n .csproj dosyas\u0131nda veya runtimeconfig.json dosyas\u0131nda yap\u0131land\u0131r\u0131labilir.\n<\/p>\n \n Hem \u0130\u015f \u0130stasyonu hem de Sunucu GC, e\u015fzamanl\u0131 (concurrent) veya e\u015fzamans\u0131z (non-concurrent) modda \u00e7al\u0131\u015fabilir:<\/p>\n \n GC, otomatik bir s\u00fcre\u00e7 olsa da, geli\u015ftiricilerin kod yazma \u015fekli GC'nin performans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde etkileyebilir. K\u00f6t\u00fc tasarlanm\u0131\u015f kod, GC'nin daha s\u0131k \u00e7al\u0131\u015fmas\u0131na, daha uzun duraklamalara ve dolay\u0131s\u0131yla uygulaman\u0131n yava\u015flamas\u0131na neden olabilir.\n<\/p>\n \n Ne kadar \u00e7ok nesne tahsis ederseniz, GC'nin o kadar s\u0131k \u00e7al\u0131\u015fmas\u0131 gerekir. \u00d6zellikle k\u0131sa \u00f6m\u00fcrl\u00fc nesnelerin yo\u011fun bir \u015fekilde olu\u015fturulmas\u0131 ve hemen ard\u0131ndan \u00e7\u00f6p haline gelmesi, Gen 0 toplamalar\u0131n\u0131 art\u0131r\u0131r. Performans kritik yollarda gereksiz nesne tahsislerinden ka\u00e7\u0131nmak \u00f6nemlidir.\n<\/p>\n \n Nesneleri gere\u011finden uzun s\u00fcre canl\u0131 tutmak (\u00f6rne\u011fin, bir \u00f6nbelle\u011fe al\u0131nm\u0131\u015f nesneye referans\u0131 temizlemeyi unutmak), nesnenin daha y\u00fcksek jenerasyonlara y\u00fckselmesine ve daha maliyetli GC d\u00f6ng\u00fclerine neden olabilir. M\u00fcmk\u00fcn oldu\u011funca k\u0131sa \u00f6m\u00fcrl\u00fc nesneler kullanmaya \u00e7al\u0131\u015f\u0131n.\n<\/p>\n \n LOH'a s\u0131k s\u0131k b\u00fcy\u00fck nesneler tahsis etmek ve bunlar\u0131 serbest b\u0131rakmak, LOH'ta par\u00e7alanmaya yol a\u00e7abilir. LOH kompaktlanmad\u0131\u011f\u0131 i\u00e7in, par\u00e7alanma, gelecekteki b\u00fcy\u00fck nesne tahsisleri i\u00e7in yeterli biti\u015fik alan bulunamamas\u0131na ve \"OutOfMemoryException\" hatalar\u0131na neden olabilir. B\u00fcy\u00fck nesneleri yeniden kullanmak (object pooling) veya daha k\u00fc\u00e7\u00fck par\u00e7alara b\u00f6lmek bu sorunu hafifletebilir.\n<\/p>\n \n Bazen bir nesneye eri\u015fime ihtiyac\u0131n\u0131z olur, ancak bu eri\u015fimin nesnenin GC taraf\u0131ndan toplanmas\u0131n\u0131 engellemesini istemezsiniz (\u00f6rne\u011fin, bir \u00f6nbellek). Bu durumlarda <\/code><\/p>\n \n GC sadece y\u00f6netilen belle\u011fi y\u00f6netir. Veritaban\u0131 ba\u011flant\u0131lar\u0131, dosya kollar\u0131, a\u011f soketleri gibi y\u00f6netilmeyen kaynaklar GC taraf\u0131ndan otomatik olarak serbest b\u0131rak\u0131lmaz. Bu t\u00fcr kaynaklar\u0131 kullanan nesneler <\/code><\/p>\n \n \u00c7o\u011fu i\u015f uygulamas\u0131 i\u00e7in varsay\u0131lan GC ayarlar\u0131 yeterlidir. Ancak belirli senaryolarda, GC'yi anlamak ve optimize etmek kritik hale gelir.\n<\/p>\n \n D\u00fc\u015f\u00fck gecikme s\u00fcresi (low latency) gerektiren finansal uygulamalar, oyun motorlar\u0131 veya ger\u00e7ek zamanl\u0131 sistemler gibi y\u00fcksek performansl\u0131 uygulamalarda, GC duraklamalar\u0131 (pauses) kabul edilemez olabilir. Bu t\u00fcr uygulamalarda, bellek tahsislerini minimize etmek ve GC'nin \u00e7al\u0131\u015fma s\u0131kl\u0131\u011f\u0131n\u0131 azaltmak hayati \u00f6nem ta\u015f\u0131r.\n<\/p>\n \n GC y\u00f6netilen bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 \u00f6nlese de, geli\u015ftiriciler hala \"mant\u0131ksal\" bellek s\u0131z\u0131nt\u0131lar\u0131na neden olabilirler. \u00d6rne\u011fin, art\u0131k kullan\u0131lmayan bir nesneye g\u00fc\u00e7l\u00fc bir referans tutmaya devam etmek (\u00f6rne\u011fin, bir event handler aboneli\u011fini kald\u0131rmay\u0131 unutmak veya statik bir koleksiyonda gereksiz nesneleri tutmak), nesnenin GC taraf\u0131ndan toplanmas\u0131n\u0131 engeller ve bellek kullan\u0131m\u0131n\u0131n s\u00fcrekli artmas\u0131na neden olur.\n<\/p>\n \n GC, toplama yaparken uygulaman\u0131n bir k\u0131sm\u0131n\u0131 veya tamam\u0131n\u0131 durdurabilir. Bu duraklamalar, uygulaman\u0131n yan\u0131t s\u00fcresini (response time) etkiler. \u00d6zellikle Sunucu GC'de, daha y\u00fcksek verim i\u00e7in daha uzun duraklamalar kabul edilebilirken, \u0130\u015f \u0130stasyonu GC'de daha k\u0131sa duraklamalar hedeflenir. Uygulaman\u0131z\u0131n gecikme gereksinimleri, GC modunuzu ve optimizasyon stratejilerinizi belirleyecektir.\n<\/p>\n \n G\u00f6m\u00fcl\u00fc sistemler, IoT cihazlar\u0131 veya d\u00fc\u015f\u00fck bellekli sunucular gibi kaynak k\u0131s\u0131tl\u0131 ortamlarda, bellek kullan\u0131m\u0131 her zaman kritik bir konudur. Bu t\u00fcr ortamlarda, GC'nin bellek t\u00fcketimi ve \u00e7al\u0131\u015fma s\u0131kl\u0131\u011f\u0131 do\u011frudan uygulaman\u0131n genel performans\u0131n\u0131 ve kararl\u0131l\u0131\u011f\u0131n\u0131 etkiler.\n<\/p>\n \n GC'nin daha verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak ve uygulaman\u0131z\u0131n performans\u0131n\u0131 art\u0131rmak i\u00e7in baz\u0131 pratik ipu\u00e7lar\u0131 ve en iyi uygulamalar \u015funlard\u0131r:\n<\/p>\n \n S\u0131k s\u0131k olu\u015fturulan ve yok edilen nesneler i\u00e7in nesne havuzlama kullanmak, bellek tahsislerini ve dolay\u0131s\u0131yla GC y\u00fck\u00fcn\u00fc azaltabilir. Nesneleri bir havuzdan al\u0131p i\u015finiz bitti\u011finde havuza geri d\u00f6nd\u00fcrerek, GC'nin bu nesneleri tekrar tekrar toplamas\u0131na gerek kalmaz.\n<\/p>\n \n Yap\u0131lar (structs) gibi de\u011fer tipleri, y\u0131\u011f\u0131nda (stack) veya i\u00e7eren nesnenin i\u00e7inde (inline) depoland\u0131\u011f\u0131 i\u00e7in GC taraf\u0131ndan y\u00f6netilmezler. K\u00fc\u00e7\u00fck, k\u0131sa \u00f6m\u00fcrl\u00fc ve s\u0131k\u00e7a kullan\u0131lan veri yap\u0131lar\u0131 i\u00e7in de\u011fer tipleri kullanmak, y\u0131\u011f\u0131n \u00fczerinde tahsis edilen nesne say\u0131s\u0131n\u0131 azaltarak GC \u00fczerindeki bask\u0131y\u0131 hafifletebilir. Ancak, b\u00fcy\u00fck de\u011fer tipleri kopyalama maliyetini art\u0131rabilir, bu y\u00fczden dikkatli kullan\u0131lmal\u0131d\u0131r.\n<\/p>\n \n String'ler .NET'te de\u011fi\u015fmez (immutable) referans tipleridir. Her string manip\u00fclasyonu (birle\u015ftirme, de\u011fi\u015ftirme vb.) yeni bir string nesnesi olu\u015fturur. Yo\u011fun string i\u015flemleri yaparken <\/code><\/p>\n \n Uygulaman\u0131zdaki bellek sorunlar\u0131n\u0131 veya GC performans darbo\u011fazlar\u0131n\u0131 tespit etmek i\u00e7in Visual Studio'nun yerle\u015fik profilleyicisi, dotMemory, ANTS Memory Profiler gibi ara\u00e7lar\u0131 kullan\u0131n. Bu ara\u00e7lar, bellek tahsislerini, nesne \u00f6m\u00fcrlerini ve GC \u00e7al\u0131\u015fma s\u00fcrelerini g\u00f6rselle\u015ftirerek optimizasyon alanlar\u0131n\u0131 belirlemenize yard\u0131mc\u0131 olur.\n<\/p>\n \n .NET'in \u00c7\u00f6p Toplay\u0131c\u0131s\u0131, geli\u015ftiricilerin bellek y\u00f6netimiyle ilgili karma\u015f\u0131k sorunlarla u\u011fra\u015fmas\u0131n\u0131 engelleyerek \u00fcretkenli\u011fi art\u0131ran g\u00fc\u00e7l\u00fc bir mekanizmad\u0131r. Ancak, GC'nin nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, jenerasyonel yap\u0131s\u0131n\u0131 ve performans \u00fczerindeki etkilerini anlamak, \u00f6zellikle y\u00fcksek performansl\u0131 veya kaynak k\u0131s\u0131tl\u0131 uygulamalar geli\u015ftirirken hayati \u00f6neme sahiptir. Bellek tahsislerini minimize etmek, nesne \u00f6m\u00fcrlerini do\u011fru y\u00f6netmek, y\u00f6netilmeyen kaynaklar\u0131 \n GC, genellikle bir performans sorunu de\u011fildir; aksine, bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 \u00f6nleyerek ve bellek y\u00f6netimini otomatikle\u015ftirerek genel uygulama kararl\u0131l\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 art\u0131r\u0131r. Ancak, yanl\u0131\u015f kodlama pratikleri (gereksiz nesne tahsisleri, uzun \u00f6m\u00fcrl\u00fc gereksiz nesneler) GC'nin daha s\u0131k ve daha uzun \u00e7al\u0131\u015fmas\u0131na neden olabilir, bu da duraklamalara ve dolay\u0131s\u0131yla alg\u0131lanan performansta d\u00fc\u015f\u00fc\u015fe yol a\u00e7abilir.\n<\/p>\n \n Hay\u0131r, \n GC, \"y\u00f6netilen\" bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 (yani art\u0131k eri\u015filemeyen nesnelerin bellekte kalmas\u0131) engeller. Ancak, \"mant\u0131ksal\" bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 engelleyemez. Bir nesneye hala g\u00fc\u00e7l\u00fc bir referans tutuluyorsa (\u00f6rne\u011fin, bir koleksiyonda gereksiz yere tutulan bir nesne veya kald\u0131r\u0131lmam\u0131\u015f bir olay i\u015fleyicisi), GC o nesnenin \u00e7\u00f6p oldu\u011funu bilemez ve onu toplamaz. Bu t\u00fcr s\u0131z\u0131nt\u0131lar geli\u015ftiricinin sorumlulu\u011fundad\u0131r.\n<\/p>\n \n B\u00fcy\u00fck Nesne Y\u0131\u011f\u0131n\u0131 (LOH), 85 KB'den b\u00fcy\u00fck nesneler i\u00e7in ayr\u0131lm\u0131\u015f \u00f6zel bir aland\u0131r. LOH'taki nesneler, performans maliyeti nedeniyle kompaktlanmaz (ta\u015f\u0131nmaz). Bu durum, LOH'ta par\u00e7alanmaya yol a\u00e7abilir ve gelecekteki b\u00fcy\u00fck nesne tahsisleri i\u00e7in yeterli biti\u015fik alan bulunamamas\u0131na neden olabilir. LOH'u verimli kullanmak, uygulaman\u0131n genel bellek performans\u0131n\u0131 etkiler.<\/p>\n","protected":false},"excerpt":{"rendered":"Modern yaz\u0131l\u0131m geli\u015ftirmenin temel ta\u015flar\u0131ndan biri olan bellek y\u00f6netimi, uygulamalar\u0131n performans\u0131 ve kararl\u0131l\u0131\u011f\u0131 \u00fczerinde do\u011frudan bir etkiye…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1340],"tags":[],"class_list":{"0":"post-39491","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-net","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n\n\n
\n \nJenerasyon<\/th>\n \u00d6m\u00fcr<\/th>\n Toplama S\u0131kl\u0131\u011f\u0131<\/th>\n Boyut<\/th>\n \u00d6zellik<\/th>\n<\/tr>\n<\/thead>\n \n Gen 0<\/td>\n K\u0131sa \u00f6m\u00fcrl\u00fc<\/td>\n \u00c7ok s\u0131k<\/td>\n K\u00fc\u00e7\u00fck<\/td>\n Yeni nesneler burada ba\u015flar.<\/td>\n<\/tr>\n \n Gen 1<\/td>\n Orta \u00f6m\u00fcrl\u00fc<\/td>\n Orta<\/td>\n Orta<\/td>\n Gen 0’dan hayatta kalanlar.<\/td>\n<\/tr>\n \n Gen 2<\/td>\n Uzun \u00f6m\u00fcrl\u00fc<\/td>\n Seyrek<\/td>\n B\u00fcy\u00fck<\/td>\n Gen 1’den hayatta kalanlar ve LOH. En maliyetli toplama.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n GC Tetikleyicileri ve T\u00fcrleri<\/h3>\n
Otomatik Tetikleyiciler<\/h4>\n
\n
Manuel Tetikleme (GC.Collect()) ve Riskleri<\/h4>\n
GC.Collect()<\/code> metodunu \u00e7a\u011f\u0131rarak GC’yi manuel olarak tetikleyebilirler. Ancak, bu genellikle tavsiye edilmez<\/strong>. GC.Collect()<\/code>‘i \u00e7a\u011f\u0131rmak, GC’nin kendi optimizasyonlar\u0131n\u0131 bozabilir ve performans\u0131 d\u00fc\u015f\u00fcrebilir. Sadece \u00e7ok \u00f6zel durumlarda ve GC’nin otomatik tetikleyicilerinin yetersiz kald\u0131\u011f\u0131 senaryolarda (\u00f6rne\u011fin, bir test ortam\u0131nda bellek s\u0131z\u0131nt\u0131s\u0131n\u0131 do\u011frulamak i\u00e7in) kullan\u0131lmal\u0131d\u0131r.\n<\/p>\n\n\/\/ GC'yi manuel olarak tetiklemek (genellikle tavsiye edilmez!)\nGC.Collect();\nGC.WaitForPendingFinalizers(); \/\/ Finalizer'lar\u0131n bitmesini bekler\n<\/pre>\n\u0130\u015f \u0130stasyonu (Workstation) ve Sunucu (Server) GC<\/h4>\n
\n
E\u015fzamanl\u0131 (Concurrent) ve E\u015fzamans\u0131z (Non-Concurrent) GC<\/h4>\n
\n
GC Performans\u0131n\u0131 Etkileyen Fakt\u00f6rler ve Optimizasyon<\/h3>\n
Bellek Ay\u0131rma H\u0131z\u0131<\/h4>\n
Nesne \u00d6mr\u00fc Y\u00f6netimi<\/h4>\n
B\u00fcy\u00fck Nesne Y\u0131\u011f\u0131n\u0131 (LOH) ve Par\u00e7alanma<\/h4>\n
Zay\u0131f Referanslar (Weak References)<\/h4>\n
WeakReference<\/code> kullan\u0131labilir. WeakReference<\/code>, bir nesneye zay\u0131f bir referans tutar, bu da GC'nin nesneyi toplamas\u0131na engel olmaz. E\u011fer nesne toplan\u0131rsa, WeakReference<\/code>'\u0131n hedefi null<\/code> olur.\n<\/p>\n\nvar strongRef = new object();\nvar weakRef = new WeakReference(strongRef);\n\n\/\/ strongRef hala canl\u0131 oldu\u011fu s\u00fcrece weakRef.Target null olmaz\nConsole.WriteLine(weakRef.Target != null); \/\/ True\n\nstrongRef = null; \/\/ strongRef'i null yaparak nesneye olan tek g\u00fc\u00e7l\u00fc referans\u0131 kald\u0131r\u0131yoruz\nGC.Collect(); \/\/ GC'yi tetikleyerek nesnenin toplanmas\u0131n\u0131 sa\u011fl\u0131yoruz (genellikle tavsiye edilmez)\nGC.WaitForPendingFinalizers();\n\nConsole.WriteLine(weakRef.Target != null); \/\/ False (nesne toplanm\u0131\u015f olabilir)\n<\/pre>\nIDisposable<\/code> ve using<\/code> Blo\u011fu<\/h4>\nIDisposable<\/code> aray\u00fcz\u00fcn\u00fc uygulamal\u0131 ve Dispose()<\/code> metodunda y\u00f6netilmeyen kaynaklar\u0131 serbest b\u0131rakmal\u0131d\u0131r. using<\/code> blo\u011fu, IDisposable<\/code> nesnelerinin Dispose()<\/code> metodunu otomatik olarak \u00e7a\u011f\u0131rman\u0131n g\u00fcvenli ve etkili bir yoludur.\n<\/p>\n\n\/\/ using blo\u011fu ile y\u00f6netilmeyen kaynaklar\u0131n do\u011fru \u015fekilde serbest b\u0131rak\u0131lmas\u0131\nusing (var fileStream = new FileStream(\"data.txt\", FileMode.Open))\n{\n \/\/ Dosya ak\u0131\u015f\u0131 ile i\u015flemler yap\n \/\/ using blo\u011fundan \u00e7\u0131k\u0131ld\u0131\u011f\u0131nda fileStream.Dispose() otomatik \u00e7a\u011fr\u0131l\u0131r\n}\n\/\/ fileStream nesnesi burada toplanabilir ve dosya kolu serbest b\u0131rak\u0131lm\u0131\u015ft\u0131r.\n<\/pre>\nGC Ne Zaman \u00d6nem Kazan\u0131r?<\/h3>\n
Y\u00fcksek Performansl\u0131 Uygulamalar<\/h4>\n
Bellek S\u0131z\u0131nt\u0131lar\u0131 (Memory Leaks)<\/h4>\n
Gecikme (Latency) ve Duraklamalar (Pauses)<\/h4>\n
Kaynak K\u0131s\u0131tl\u0131 Ortamlar<\/h4>\n
Pratik \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h3>\n
Nesne Havuzlama (Object Pooling)<\/h4>\n
De\u011fer Tipleri (Value Types) Kullan\u0131m\u0131<\/h4>\n
String \u0130\u015flemlerinde Dikkat<\/h4>\n
StringBuilder<\/code> kullanmak, gereksiz ara string nesnelerinin olu\u015fmas\u0131n\u0131 engelleyerek GC y\u00fck\u00fcn\u00fc azalt\u0131r.\n<\/p>\n\n\/\/ K\u00f6t\u00fc \u00f6rnek: \u00c7ok say\u0131da string nesnesi olu\u015fturur\nstring result = \"\";\nfor (int i = 0; i < 1000; i++)\n{\n result += i.ToString();\n}\n\n\/\/ \u0130yi \u00f6rnek: Sadece bir StringBuilder nesnesi ve sonunda bir string nesnesi olu\u015fturur\nStringBuilder sb = new StringBuilder();\nfor (int i = 0; i < 1000; i++)\n{\n sb.Append(i);\n}\nstring finalResult = sb.ToString();\n<\/pre>\nProfilleme Ara\u00e7lar\u0131 Kullan\u0131m\u0131<\/h4>\n
Sonu\u00e7<\/h3>\n
IDisposable<\/code> ile serbest b\u0131rakmak ve uygun GC modunu se\u00e7mek gibi pratik ipu\u00e7lar\u0131, uygulaman\u0131z\u0131n daha verimli ve kararl\u0131 \u00e7al\u0131\u015fmas\u0131na yard\u0131mc\u0131 olacakt\u0131r. Unutmay\u0131n, GC sizin i\u00e7in \u00e7al\u0131\u015f\u0131r, ancak onu anlamak, en iyi sonu\u00e7lar\u0131 elde etmenizi sa\u011flar.\n<\/p>\nSSS (S\u0131k Sorulan Sorular)<\/h3>\n
GC bir performans sorunu mudur?<\/h4>\n
GC.Collect()<\/code> her zaman iyi bir fikir midir?<\/h4>\nGC.Collect()<\/code>'i manuel olarak \u00e7a\u011f\u0131rmak genellikle k\u00f6t\u00fc bir fikirdir ve tavsiye edilmez. GC, ne zaman toplama yapaca\u011f\u0131n\u0131 belirlemek i\u00e7in karma\u015f\u0131k algoritmalar ve optimizasyonlar kullan\u0131r. Manuel tetikleme, bu optimizasyonlar\u0131 bozabilir ve uygulaman\u0131z\u0131n performans\u0131n\u0131 d\u00fc\u015f\u00fcrebilir. Sadece \u00e7ok \u00f6zel ve nadir durumlarda kullan\u0131lmal\u0131d\u0131r.\n<\/p>\nBellek s\u0131z\u0131nt\u0131lar\u0131 GC taraf\u0131ndan engellenir mi?<\/h4>\n
LOH neden \u00f6zeldir?<\/h4>\n