[{"data":1,"prerenderedAt":431},["ShallowReactive",2],{"site-header":3,"site-footer-license":42,"article-garbage-collector-dituduh-bikin-aplikasi-lemot-with-latest":46},{"navigations":4},[5,20,37],{"collection":6,"item":7},"series",{"__typename":6,"title":8,"slug":9,"children_series":10},"Artikel","all",[11,14,17],{"title":12,"slug":13},"Algoritma dan Struktur Data","algoritma-struktur-data",{"title":15,"slug":16},"Konsep Dasar Pemrograman","konsep-dasar-pemrograman",{"title":18,"slug":19},"Kecerdasan Artifisial","kecerdasan-artifisial",{"collection":6,"item":21},{"__typename":6,"title":22,"slug":23,"children_series":24},"Tutorial","tutorial",[25,28,31,34],{"title":26,"slug":27},"Belajar Java","belajar-java",{"title":29,"slug":30},"Belajar Pascal","belajar-pascal",{"title":32,"slug":33},"Belajar Python","belajar-python",{"title":35,"slug":36},"Belajar Golang","belajar-golang",{"collection":6,"item":38},{"__typename":6,"title":39,"slug":40,"children_series":41},"Lab","lab",[],{"name":43,"url":44,"show":45},"CC BY-SA","https://creativecommons.org/licenses/by-sa/4.0/",false,{"article":47,"renderedBody":385,"renderedTakeaway":386,"latestArticles":387,"toc":404},{"prerequisite":48,"id":49,"title":50,"slug":51,"excerpt":52,"published_at":48,"thumbnail_image":48,"tags":53,"reading_time":60,"takeway":61,"body":62,"authors":63,"series":64},null,"113","Garbage Collector dituduh bikin aplikasi lemot. Seberapa adil tuduhan itu?","garbage-collector-dituduh-bikin-aplikasi-lemot","GC sering jadi tersangka utama tiap aplikasi melambat, dan banyak yang percaya dia jalan pakai timer tiap beberapa detik. Dua-duanya nggak sepenuhnya benar. Yuk bedah cara kerja GC dari dalam, plus satu pengecualian yang bikin Discord kesakitan tiap 2 menit. 🤔",[54,55,56,57,58,59],"backend","performance","golang","jvm","garbage-collector","memory",7,"Garbage Collector modern memicu dirinya sendiri lewat ambang alokasi, bukan timer, dan buat sebagian besar aplikasi cara itu justru menguntungkan.\n- Jeda GC di runtime modern seperti Go dan ZGC sudah sub-milidetik dan nggak tumbuh seiring ukuran heap, jadi tuduhan \"GC bikin lemot\" cuma benar di sistem yang tenggat waktunya mikrodetik.\n- Harga memori dari GC itu nyata tapi bisa diputar: GOGC yang tinggi menghemat CPU dengan tambahan RAM, sementara GOMEMLIMIT yang terlalu ketat justru berujung thrashing.\n- Yang bikin GC jadi masalah bukan kecepatannya, tapi ketidakmampuan menjadwalkan jedanya, jadi selama tenggat aplikasimu longgar tersangkanya salah tangkap.\n- Kasus Instagram menunjukkan sebagian masalah GC bisa dibereskan lewat konfigurasi, dan itu pun cuma masuk akal kalau prosesnya memang berumur pendek.","Kalau kamu pernah mampir ke forum pemrograman, kamu pasti pernah ketemu kalimat ini: \"mau aplikasi kencang? Jauhi bahasa ber-*GC* kayak Java, Go, C#, Python, atau *JavaScript*, pakai C, C++, atau Rust aja.\" Anggapan itu berumur panjang, dan di baliknya ada satu gambaran soal cara kerja GC yang perlu kita periksa.\n\nAda benarnya, sih: GC emang beneran makan sumber daya, dan itu bukan hal yang bisa dibantah. Cuma, dua hal yang sering dianggap pasti soal GC—dia jalan tiap beberapa detik, dan dia selalu bikin lemot—lebih baik kamu lihat sendiri mekanismenya. Di [artikel sebelumnya](https://invasikode.com/p/aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu) kita udah lihat Discord dan Cloudflare menghadapi batasan ini dengan mengukur dulu, bukan menebak. Sekarang waktunya ngintip batasan itu dari dalam, yuk. 🙂\n\n## GC jalan pakai timer?\n\nSketsa paling gampang buat mbayangin cara kerja GC itu kira-kira begini:\n\n```text\nwhile true:\n    sleep(5)                        # tunggu 5 detik\n    cari_objek_yang_udah_nggak_dipakai()\n```\n\nTapi bentuk aslinya tuh nggak kayak gitu. Kalau benar ada *timer* di situ, servermu yang nganggur di tengah malam bakal tetap sibuk memindai memori tiap lima detik: CPU-nya kebakar, tagihan *cloud*-nya naik, dan yang dibersihkan cuma kekosongan. Untungnya, GC modern nggak sedungu itu. 😅\n\nYang dipakai hampir semua *runtime* modern sekarang adalah **ambang alokasi**, bukan jam. GC cuma bangun kalau memori yang dialokasikan aplikasi nyentuh batas tertentu. Di Go, batas itu diatur lewat *environment variable* `GOGC`, yang default-nya 100.\n\nAngka 100 itu artinya begini: GC membiarkan *heap* tumbuh sampai sekitar dua kali lipat memori hidup. Contohnya nih, kalau setelah satu siklus selesai memori yang masih hidup tinggal 10 MB, GC baru jalan lagi saat heap menyentuh 20 MB. Selama aplikasimu main di bawah angka itu, GC tidur nyenyak. Masuk akal kan?\n\nAngka 100-nya sendiri bisa kamu putar. Turunin ke 50, targetnya jadi sekitar 15 MB—GC lebih sering jalan, tapi RAM lebih hemat. Naikin ke 200, targetnya jadi sekitar 30 MB—GC lebih jarang jalan, tapi RAM lebih boros. Rumus lengkapnya ada di [panduan resmi GC Go](https://go.dev/doc/gc-guide) kalau kamu mau ngitung sendiri, tapi intinya cuma itu.\n\nJadi jawabannya: nggak. GC nggak dijalankan pakai timer.\n\n### Tapi ada juga yang memang berbasis waktu\n\nDi sinilah pertanyaannya jadi lebih menarik: beberapa *runtime* memang punya pemicu berbasis waktu. Go salah satunya. Dia **memaksa GC jalan minimal tiap 2 menit**, terlepas dari seberapa lambat *heap*-nya tumbuh. Bukan gosip forum, itu ada sebagai [komentar di kode sumber Go](https://go.googlesource.com/go/+/refs/heads/master/src/runtime/proc.go): kalau sudah 2 menit nggak ada koleksi, satu siklus dipaksa jalan.\n\nKenapa sampai perlu? Karena ambang `GOGC` cuma berguna kalau aplikasimu rajin mengalokasi. Kalau *live heap*-nya besar tapi alokasinya lambat—persis seperti Read States di Discord—ambang itu nggak pernah kesentuh, dan timer 2 menit inilah yang akhirnya ambil alih. Setiap kali dia jalan, GC harus memindai seluruh *LRU cache* yang isinya jutaan *user*. Dari situ [blog Discord](https://discord.com/blog/why-discord-is-switching-from-go-to-rust) sendiri nyimpulin kenapa grafik mereka punya *spike* yang datang rapi tiap sekitar 2 menit, dan kenapa usaha nge-*tuning* `GC percent` gagal total.\n\nGo bukan satu-satunya. V8 di Chrome punya [*idle-time* GC](https://v8.dev/blog/free-garbage-collection): kerja bersih-bersihnya dititipkan ke *idle task* yang dijadwalkan browser, bukan ke jadwal tetap. HotSpot malah menyediakan opsi [`G1PeriodicGCInterval`](https://openjdk.org/jeps/346) yang memicu siklus GC berkala saat aplikasinya menganggur, biasanya buat balikin memori ke sistem operasi.\n\nSatu catatan jujur sebelum lanjut: kasus Discord itu terjadi di 2020, waktu Go masih di seri 1.8–1.10, dan cara kerja GC-nya sudah banyak berubah sejak itu. Yang nggak berubah: selama heap-mu gede dan isinya banyak *pointer*, memindainya tetap kerja yang harus dibayar. Perubahan itulah yang mendorong Go 1.19 menambah `GOMEMLIMIT`, supaya kamu bisa nentuin batas memori absolut, bukan cuma rasio.\n\nJadi kalau selama ini kamu mbayangin GC punya jadwal rutin, tebakanmu nggak ngawur. Yang bikin beda cuma porsinya: pemicu berbasis waktu itu jaring pengaman atau kerja sampingan, bukan mesin utamanya.\n\n## GC itu sebenarnya ngapain di dalam?\n\nGC tuh ibarat tukang bersih-bersih yang nggak keliling tiap jam: dia baru bergerak kalau ada yang memanggilnya. Dan hampir semua GC modern ikut keluarga **tracing**, dengan pola dasar yang sama: *mark*, lalu *sweep*. Biar kebayang, kita bedah dua fase itu satu-satu.\n\n### Gimana GC tahu objek mana yang masih hidup?\n\nGC nggak baca memori dari alamat nol secara buta. Dia mulai dari **GC roots**: variabel lokal di *stack*, variabel global, dan register CPU. Dari situ dia jalan ngikutin *pointer* seperti menelusuri pohon. Objek yang kejangkau ditandai hidup. Setelah penelusuran selesai, heap disapu dan semua yang nggak ketandai dikembalikan ke daftar bebas, siap dipakai ulang tanpa minta alokasi baru ke sistem operasi.\n\nSatu detail yang sering kelewat: GC Go itu *non-moving*. Objeknya nggak digeser-geser di memori. Bahasa lain ada yang menggeser objeknya (*compacting*) supaya memori lebih rapat, tapi harganya semua *pointer* harus ikut diperbarui. Java dan V8 memilih jalan tengah dengan **generational** *collector*, yang nebak bahwa objek muda lebih cepat mati, jadi nggak semua objek perlu diperiksa sama sering.\n\n### Tracing vs menghitung referensi\n\nAda dua keluarga besar di sini. *Tracing* dipakai Go, Java, dan V8. *Reference counting* dipakai Python dan Swift, dengan cara yang beda: tiap objek nyimpen jumlah referensinya, dan begitu angkanya nol, memori langsung dibebaskan. Python bahkan pakai dua-duanya sekaligus, karena *refcount* sendirian nggak bisa ngurus objek yang saling tunjuk membentuk lingkaran.\n\nPembagian ini penting buat diingat, soalnya dari sini kebijakan buat nge-*tune* GC jadi beda-beda: mulai dari `GOGC` dan `GOMEMLIMIT` di Go, pilihan *collector* G1 sampai ZGC di JVM, sampai pilihan buat mematikan sebagian GC di Python.\n\n## Terus biaya performanya di mana?\n\nKalau algoritmanya cuma jalanin *pointer*, apa yang sebenarnya kita bayar? Tiga hal ini:\n\n- Jeda singkat di peralihan fase. Di Go, aplikasi cuma benar-benar berhenti (*stop-the-world*) sebentar aja di transisi antara *mark* dan *sweep*, dan panjangnya sengaja dibikin nggak tumbuh seiring ukuran *heap*. Di JVM, [ZGC](https://wiki.openjdk.org/display/zgc/Main) malah sudah jadi fitur produksi sejak JDK 15 dengan jeda sub-milidetik, bahkan di heap yang ukurannya bukan main.\n- Porsi CPU yang disedot GC. Fase *mark* ngambil sekitar 25% CPU, dan itu artinya *thread* aplikasimu rebutan prosesor. Yang paling bikin kesel: kalau alokasimu cepat, goroutine-mu sendiri ikut ditarik buat bantu GC (*GC assist*).\n- Overhead memori. `GOGC=100` artinya kamu nyiapin ruang sekitar dua kali lipat memori hidup. Naikin `GOGC`, GC jadi jarang jalan dan CPU lebih lega, tapi RAM lebih boros. Pasang `GOMEMLIMIT` terlalu ketat, kamu dapat masalah baru bernama *thrashing*: GC jalan terus-terusan, dan aplikasi bisa melambat sampai dua kali lipat.\n\nAda juga efek samping yang lebih susah diukur: metadata GC ikut memenuhi cache CPU, jadi data logika bisnismu terdepak ke RAM yang latensinya jauh lebih tinggi. Ini bukan angka yang keluar dari halaman dokumentasi mana pun, tapi masuk akal, dan Instagram sendiri nyebut soal naiknya *cache hit ratio* sebagai salah satu alasan mereka [mematikan GC di Python-nya](https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172).\n\n## Kapan GC beneran jadi masalah?\n\nDi sinilah keputusannya bisa dipertanggungjawabkan, dan jawabannya bergantung pada seberapa ketat tenggat waktumu.\n\n- Web API dan *microservice* biasa. Bukan masalah. Jeda setengah milidetik di *request* yang latensi jaringannya 30–50 ms nggak akan terasa siapa pun, dan sebagai gantinya kamu dapat bahasa yang bebas dari satu kelas *bug* paling mahal. Microsoft sendiri [bilang sekitar 70% *CVE*](https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactive-approach-to-more-secure-code) yang mereka perbaiki tiap tahun itu masalah *memory safety*, dan itu di kode C dan C++.\n- Game yang ngejar 60 FPS atau lebih. Coba bayangin deh, di 60 FPS satu *frame* cuma punya 16,6 ms, dan di 144 FPS sisanya tinggal 6,9 ms. Jeda GC 10 ms aja udah cukup bikin *frame*-nya patah-patah.\n- Kernel, *driver*, dan sistem *hard real-time*. Di sini yang penting bukan kecepatan rata-rata, tapi determinisme. Sistem yang cuma boleh telat mikrodetik nggak bisa nyerahin jadwalnya ke GC.\n- *High-frequency trading*. Yang diperdagangkan di sini mikrodetik. Distribusi jeda yang nggak bisa ditebak sama mahalnya dengan jedanya sendiri.\n\nLihat polanya: yang bikin GC jadi masalah bukan \"GC lambat\", tapi \"GC nggak bisa dijadwalkan\". Selama tenggat aplikasimu longgar, tuduhan itu jatuh dengan sendirinya.\n\n## Jadi, GC itu masalah atau bukan?\n\nBuat sebagian besar software yang kamu bangun, jawabannya: bukan. GC menukar sedikit RAM dan sedikit CPU dengan hilangnya satu kelas *bug* paling mahal yang pernah ada di dunia C—dan itu Microsoft sendiri yang bilang, bukan penggemar Go.\n\nInstagram malah bisa mematikan *cyclic collector* di Python-nya dan langsung [jalan 10% lebih efisien](https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172) tanpa pindah bahasa. Tapi itu cuma masuk akal karena prosesnya berumur pendek dan sering di-*restart*.\n\nJadi yang perlu kita lakukan bukan menghindari GC, tapi tahu kapan dia mulai kebebanan. Kalau grafik *latency*-mu punya *spike* rapi tiap beberapa menit, tersangkanya mungkin GC, dan kamu bahkan bisa nebak dari durasi *spike*-nya. Tapi buktikan dulu pakai *profiler*, jangan cuma dari perasaan.\n\nSelamat membedah grafik *latency*-mu, dan semoga tersangkanya bukan yang salah tangkap. 👋",[],{"id":65,"title":8,"slug":9,"articles":66,"parent_series":48},"9",[67,77,85,96,98,108,118,126,137,145,154,160,170,178,187,196,203,212,221,228,237,244,253,260,268,276,284,291,299,307,317,326,334,344,352,363,371,378],{"id":68,"title":69,"slug":70,"excerpt":71,"thumbnail_image":48,"tags":72},"110","Ketika Pilih Framework Cuma Biar Kelihatan Beda","ketika-pilih-framework-cuma-biar-kelihatan-beda","Terakhir kali kamu milih framework atau library baru, itu karena masalahmu butuh alat itu, atau karena alatnya kedengaran keren dan belum banyak yang pakai? Pertanyaan ini nggak enak dijawab. Soalnya keputusan teknologi sering diambil dengan alasan yang nggak pernah ditulis di dokumen teknis mana pun.",[73,74,75,76],"karier","framework","opini","pengalaman",{"id":78,"title":79,"slug":80,"excerpt":81,"thumbnail_image":48,"tags":82},"109","State of JS 2025 Bilang Developer Cuma Pakai 2,6 Framework Sepanjang Karier","state-of-js-2025-developer-cuma-pakai-2-6-framework","Coba hitung semua framework yang pernah kamu coba, lalu potong jadi yang beneran dipakai buat kerjaan. Daftarnya jauh lebih pendek dari dugaan. State of JS 2025 nanya ke 13.002 developer, dan rata-ratanya cuma 2,6. Yuk, lihat angkanya bareng-bareng!",[83,84,74,73],"javascript","survei",{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":48,"tags":90},"111","Rust Masuk Kernel Linux: Revolusi Nyata atau Cuma Euforia RIIR?","rust-di-kernel-linux-revolusi-atau-cuma-hype","Selama lebih dari 30 tahun kernel Linux cuma mau bahasa C, lalu tiba-tiba Rust resmi masuk di Linux 6.1. Itu revolusi beneran atau cuma kebawa euforia meme Rewrite It In Rust? Yuk lihat datanya, bukan cuma opininya.",[91,92,93,94,95],"rust","linux","kernel","system-programming","memory-safety",{"id":49,"title":50,"slug":51,"excerpt":52,"thumbnail_image":48,"tags":97},[54,55,56,57,58,59],{"id":99,"title":100,"slug":101,"excerpt":102,"thumbnail_image":48,"tags":103},"29","Memahami Database Indexing: Rahasia Query Super Cepat","memahami-database-indexing-rahasia-query-super-cepat","Query kalian mulai lelet padahal data baru nembus jutaan baris? Sebelum buru-buru *upgrade* server, yuk cek dulu *index*-nya. Yuk, kita bedah gimana *database indexing* sebenernya kerja!",[104,105,106,107,55,54],"database","sql","postgresql","indexing",{"id":109,"title":110,"slug":111,"excerpt":112,"thumbnail_image":48,"tags":113},"30","Berkenalan dengan Bahasa Go: Kenapa Banyak Dipakai untuk Backend Modern?","berkenalan-dengan-bahasa-go-untuk-backend-modern","Kok bisa sih Go yang masih muda ini jadi bahasa andalan Docker sampai Kubernetes? Yuk, kita kenalan sama Goroutine, Channel, dan alasan dia hemat memori luar biasa!",[56,114,54,115,116,117],"go","concurrency","goroutine","system-design",{"id":119,"title":120,"slug":121,"excerpt":122,"thumbnail_image":48,"tags":123},"11","Apa Kabar JavaScript? Rilis State of JS 2022","apa-kabar-javascript-rilis-state-of-js-2022","Survei State of JS 2022 resmi dirilis dengan lonjakan responden yang luar biasa! Framework dan build tool apa saja yang berhasil mencuri perhatian tahun ini?",[83,124,125],"web","news",{"id":127,"title":128,"slug":129,"excerpt":130,"thumbnail_image":48,"tags":131},"37","Kenapa Backend Butuh Graceful Shutdown? Jangan Asal Cabut Kabel Server!","kenapa-backend-butuh-graceful-shutdown-jangan-asal-cabut-kabel-server","Pernah nggak sih, abis kalian nge-*deploy* backend, beberapa detik kemudian monitoring malah banjir *alert* **502 Bad Gateway** dari pengguna? Saldo udah kepotong tapi status order belum keburu ter-*update* di *database*. Yuk, kita bahas kenapa *graceful shutdown* itu wajib banget!",[54,132,133,134,135,117,136],"devops","fastapi","docker","kubernetes","architecture",{"id":138,"title":139,"slug":140,"excerpt":141,"thumbnail_image":48,"tags":142},"39","Database Sharding vs Partitioning: Kapan Data Perlu Dipecah?","database-sharding-vs-partitioning-kapan-data-perlu-dipecah","Tabel transaksi kalian udah nembus miliaran baris dan tiap *query* laporan bikin *CPU* melonjak 100%? Sebelum asal pecah data, yuk kita pahami dulu beda *sharding* sama *partitioning*!",[54,104,106,117,136,143,144],"sharding","scaling",{"id":146,"title":147,"slug":148,"excerpt":149,"thumbnail_image":48,"tags":150},"24","Kenapa Butuh Rate Limiting?","kenapa-butuh-rate-limiting","Pernah nggak sih endpoint login kalian diserbu bot yang nyoba nembak ribuan password cuma dalam semenit? Yuk, kita bahas kenapa Rate Limiting itu wajib, plus cara masangnya di FastAPI!",[54,151,117,152,153,133],"rate-limiting","api","redis",{"id":155,"title":156,"slug":157,"excerpt":158,"thumbnail_image":48,"tags":159},"38","Optimistic vs Pessimistic Locking: Mengatasi Rebutan Data di Database","optimistic-vs-pessimistic-locking-mengatasi-rebutan-data-di-database","Seribu orang ngeklik \"Beli Sekarang\" di detik yang sama buat rebutan 1 tiket terakhir. Kira-kira apa yang bakal terjadi di server kalian? Yuk, kita banding *pessimistic* sama *optimistic locking*!",[54,104,115,106,117,136,105],{"id":161,"title":162,"slug":163,"excerpt":164,"thumbnail_image":48,"tags":165},"26","REST API vs gRPC: Kapan Sebaiknya Mulai Pindah dari JSON?","rest-api-vs-grpc-kapan-sebaiknya-pindah-dari-json","Pernah nggak sih sistem mikroservis kalian mulai kerasa berat padahal cuma tuker-tukeran data internal? Belum tentu masalah servernya. Yuk, kita bahas kapan REST + JSON masih juara dan kapan gRPC jadi jawabannya!",[54,166,167,168,169,117],"grpc","rest-api","microservices","protobuf",{"id":171,"title":172,"slug":173,"excerpt":174,"thumbnail_image":48,"tags":175},"46","Mengapa C Mulai Ditinggalkan: Duel Filosofi Keamanan Rust vs Kesederhanaan Zig","mengapa-c-mulai-ditinggalkan-duel-filosofi-rust-vs-zig","Pernah denger kalau sekitar 70% celah keamanan kritis software modern itu asalnya dari bahasa C? Iya, bahasa yang udah jadi fondasi internet ini 😅. Yuk, kita bedah duel filosofi Rust vs Zig dan cari tahu mana yang pas buat proyek kalian!",[94,91,176,177,95],"zig","c",{"id":179,"title":180,"slug":181,"excerpt":182,"thumbnail_image":48,"tags":183},"23","Kenapa Pakai FastAPI dan Kenapa Dia Kenceng Banget?","kenapa-pakai-fastapi-dan-kenapa-dia-kenceng-banget","Sering dengar FastAPI tapi masih bingung kenapa dia bisa ngebut kayak NodeJS dan Go? Yuk, kita bedah bareng rahasia ASGI, sihir Pydantic, sampai dokumentasi otomatisnya!",[133,184,54,185,186],"python","asgi","pydantic",{"id":188,"title":189,"slug":190,"excerpt":191,"thumbnail_image":48,"tags":192},"14","Instalasi Java dengan Visual Studio Code","instalasi-java-dengan-visual-studio-code","Mau belajar ngoding Java tapi spek laptop pas-pasan buat buka IDE berat? Yuk, cari tahu cara setup VS Code biar ngoding Java tetap lancar dan enteng!",[193,194,195],"howto","java","editor",{"id":197,"title":198,"slug":199,"excerpt":200,"thumbnail_image":48,"tags":201},"15","Kenapa Ada Banyak Sekali Distro Linux?","kenapa-ada-banyak-sekali-distro-linux","Pernah bingung pas mau install Linux tapi malah disuguhi puluhan pilihan distro? Tenang, kalian nggak sendirian. Yuk, cari tahu kenapa distro Linux bisa sebanyak itu dan apa bedanya!",[92,202],"distro",{"id":204,"title":205,"slug":206,"excerpt":207,"thumbnail_image":48,"tags":208},"31","Mengenal Redis: Lebih dari Sekadar In-Memory Cache","mengenal-redis-lebih-dari-sekadar-in-memory-cache","Masih nganggep Redis cuma buat caching? Padahal dia bisa jadi leaderboard, message broker, sampai rate limiter lho. Yuk, kita bedah semua kemampuannya!",[153,54,209,210,211,184],"cache","nosql","in-memory",{"id":213,"title":214,"slug":215,"excerpt":216,"thumbnail_image":48,"tags":217},"20","Tailwind v3.0 Rilis: Ada JIT, Arbitrary Values, dan Banyak Lagi!","tailwind-v3-0-rilis-jit-arbitrary-dan-banyak-lagi","Tailwind CSS v3.0 resmi dirilis dengan segudang peningkatan performa yang bikin proses coding makin asyik. Apa aja sih fitur andalan yang wajib dicoba?",[218,219,220],"tailwind-css","css-framework","web-development",{"id":222,"title":223,"slug":224,"excerpt":225,"thumbnail_image":48,"tags":226},"18","React, Angular, atau Vue: Pilih Framework yang Mana?","react-angular-vue-pilih-framework-yang-mana","Bingung menentukan pilihan di antara React, Angular, dan Vue untuk proyek web kalian berikutnya? Tenang, yuk kita bandingkan kelebihan masing-masing di sini!",[220,227,74],"frontend",{"id":229,"title":230,"slug":231,"excerpt":232,"thumbnail_image":48,"tags":233},"19","Static Typing dan Dynamic Typing: Apa Bedanya?","static-typing-dan-dynamic-typing-apa-bedanya","Pernah bingung kenapa di Java tipe data harus dideklarasikan, sementara di Python tinggal pakai aja? Yuk, cari tahu perbedaan static typing dan dynamic typing di sini!",[234,235,236],"programming","types","comparison",{"id":238,"title":239,"slug":240,"excerpt":241,"thumbnail_image":48,"tags":242},"21","TypeScript: JavaScript dengan Gaya dan Tipe Data Statis","typescript-javascript-dengan-gaya","Pernah pusing gara-gara runtime error di JavaScript? Yuk, kenalan dengan TypeScript yang bawa fitur static typing biar kode kalian makin rapi dan aman!",[243,83,220],"typescript",{"id":245,"title":246,"slug":247,"excerpt":248,"thumbnail_image":48,"tags":249},"22","Yang Baru di Nuxt 3: Nitro Engine, Vite, dan Fitur Keren Lainnya","yang-baru-di-nuxt-3-nitro-vite-dan-banyak-lagi","Nuxt 3 hadir membawa perubahan arsitektur besar-besaran untuk menyelaraskan dengan Vue 3. Penasaran apa saja peningkatan performa dan fitur barunya?",[250,251,252],"nuxt-3","vue-3","frontend-framework",{"id":254,"title":255,"slug":256,"excerpt":257,"thumbnail_image":48,"tags":258},"112","Aplikasimu lambat, dan kamu udah kepikiran ganti bahasa. Tunggu dulu","aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu","Ada endpoint yang grafiknya spike tiap beberapa menit, dan kepikiran buat pindah dari Go ke Rust? Discord dan Cloudflare beneran melakukannya — tapi cuma setelah kehabisan cara lain dan punya datanya. Yuk, bedah gejala mana yang beneran butuh rewrite, dan mana yang cuma butuh profiling. 🤔",[54,55,56,91,117,259],"profiling",{"id":261,"title":262,"slug":263,"excerpt":264,"thumbnail_image":48,"tags":265},"32","Docker Compose untuk Developer Santai: Satu Perintah Buat Jalankan Semua Service","docker-compose-untuk-developer-santai","Pernah nggak kalian ngulang-ngulang perintah `docker run` cuma buat nyalain web, database, dan cache satu-satu? Capek, kan? Yuk, kita rapikan semuanya jadi satu file dan satu perintah!",[134,266,132,267,54],"docker-compose","containers",{"id":269,"title":270,"slug":271,"excerpt":272,"thumbnail_image":48,"tags":273},"35","Mengenal Idempotency Key: Rahasia Anti-Double Charge di API Pembayaran","mengenal-idempotency-key-rahasia-anti-double-charge-di-api-pembayaran","Pernah internet kalian ngadat pas lagi nekan tombol Bayar, terus panik ngekliknya tiga kali? Kalau endpoint-nya nggak idempotent, saldo bisa kepotong berkali-kali. Yuk, kenalan sama Idempotency Key!",[54,152,274,117,275,133,153],"idempotency","payment",{"id":277,"title":278,"slug":279,"excerpt":280,"thumbnail_image":48,"tags":281},"25","Kenapa Event Queue Bikin Backend Kalian Nggak Gampang Tumbang?","kenapa-event-queue-bikin-backend-kamu-nggak-gampang-tumbang","Pernah klik tombol Beli Sekarang dan notifikasi suksesnya muncul dalam sekejap, padahal di belakang layar ada invoice, email, sampai push notification yang harus dibuat? Rahasianya Event Queue. Yuk, kita bedah!",[54,117,282,283,136],"event-queue","message-broker",{"id":285,"title":286,"slug":287,"excerpt":288,"thumbnail_image":48,"tags":289},"36","Mencegah Efek Domino di Mikroservis dengan Circuit Breaker Pattern","mencegah-efek-domino-di-mikroservis-dengan-circuit-breaker-pattern","Pernah nggak sih, satu fitur minor di aplikasi kalian mendadak lelet, eh malah bikin halaman checkout dan login ikut down total? Itu namanya *cascading failure*. Yuk, kita bahas gimana *circuit breaker pattern* (pemutus arus) nyelametin arsitektur kalian!",[54,168,290,117,136],"circuit-breaker",{"id":292,"title":293,"slug":294,"excerpt":295,"thumbnail_image":48,"tags":296},"17","Pemrograman Asynchronous vs Multithreading, Apa Sih Bedanya?","pemrograman-asynchronous-dan-multithreading-apa-bedanya","Sering dengar istilah asynchronous dan multithreading pas ngoding tapi masih bingung bedanya? Yuk, kita bedah perbedaannya lewat analogi bikin mi instan yang gampang dipahami!",[297,115,298],"pemrograman","tips-coding",{"id":300,"title":301,"slug":302,"excerpt":303,"thumbnail_image":48,"tags":304},"16","Menggunakan TypeScript dengan Node.js dan Express","menggunakan-typescript-dengan-node-js-dan-express","Pengen bikin server Express di Node.js tapi pakai fitur-fitur keren TypeScript? Yuk, intip cara setup lengkapnya dari nol di sini!",[83,305,306,243],"nodejs","express",{"id":308,"title":309,"slug":310,"excerpt":311,"thumbnail_image":48,"tags":312},"40","Menyelami Distributed Tracing: Melacak Jejak Request di Balik Keruwetan Microservices","menyelami-distributed-tracing-melacak-jejak-request-microservices","Satu klik Checkout di backend kalian bisa memicu puluhan network call antar-service, tapi pas ada yang lambat, service mana sebenernya yang salah? Log aja nggak cukup buat njawab itu. Yuk, kita bedah Distributed Tracing!",[54,313,314,315,168,136,316],"distributed-systems","observability","open-telemetry","tracing",{"id":318,"title":319,"slug":320,"excerpt":321,"thumbnail_image":48,"tags":322},"28","Mengatasi N+1 Query Problem: Musuh Tersembunyi Performa Backend","mengatasi-n-plus-1-query-problem-musuh-tersembunyi-backend","Pernah bikin endpoint yang cuma nampilin 50 postingan beserta nama penulisnya, tapi response-nya lambat banget? Bisa jadi kalian kena N+1 Query. Yuk, kita bedah penyebabnya dan cara memberantasnya!",[104,105,323,324,325,55,54],"orm","sqlalchemy","django",{"id":327,"title":328,"slug":329,"excerpt":330,"thumbnail_image":48,"tags":331},"13","Hal yang Perlu Diperhatikan Sebelum Pindah ke Linux","hal-yang-perlu-diperhatikan-sebelum-pindah-ke-linux","Tertarik migrasi dari Windows ke Linux tapi masih ragu? Yuk, pelajari kelebihan, kekurangan, dan persiapan penting sebelum kamu benar-benar pindah!",[92,332,333],"windows","foss",{"id":335,"title":336,"slug":337,"excerpt":338,"thumbnail_image":48,"tags":339},"27","Background Worker & Task Queue: Jangan Jalankan Proses Berat di Request HTTP!","background-worker-task-queue-jangan-jalankan-proses-berat-di-http","Pernah nggak sih kalian klik Daftar Akun lalu halaman loading muter sampai 15 detik tanpa kepastian? Penyebabnya klasik banget. Yuk, kita bahas kenapa proses berat nggak boleh dijalanin di request HTTP!",[54,340,341,133,342,153,343],"task-queue","celery","rabbitmq","async",{"id":345,"title":346,"slug":347,"excerpt":348,"thumbnail_image":48,"tags":349},"12","Buat PowerShell Lebih Berwarna dengan Starship","buat-powershell-lebih-berwarna-dengan-starship","Bosen sama tampilan PowerShell yang hitam putih dan kaku? Yuk, sulap terminalmu jadi lebih interaktif, estetik, dan berwarna pakai Starship!",[350,332,351],"shell","powershell",{"id":353,"title":354,"slug":355,"excerpt":356,"thumbnail_image":48,"tags":357},"41","Log Aggregation Modern dengan Grafana Loki dan Vector: Hemat Storage Tanpa Indeks Raksasa","log-aggregation-modern-grafana-loki-vector-hemat-storage","Klaster Elasticsearch kalian rakus RAM dan boros storage, ya? Padahal nggak semua kata di log perlu diindeks, lho. Yuk, kita kenalan sama duet Grafana Loki dan Vector yang jauh lebih ramah kantong!",[54,358,359,360,361,362,132,117],"observa","logging","grafana","loki","vector",{"id":364,"title":365,"slug":366,"excerpt":367,"thumbnail_image":48,"tags":368},"45","Rate Limiting Algorithms: Token Bucket vs Leaky Bucket vs Sliding Window","rate-limiting-algorithms-token-bucket-leaky-bucket-sliding-window","Udah tahu kenapa *rate limiting* itu wajib, tapi masih bingung beda Token Bucket, Leaky Bucket, Fixed Window, dan Sliding Window? Yuk, kita adu empat algoritma ini bareng-bareng dan cari tahu mana yang paling pas buat API kalian!",[54,117,151,153,369,136,370],"api-gateway","traffict-management",{"id":372,"title":373,"slug":374,"excerpt":375,"thumbnail_image":48,"tags":376},"34","Kenapa Backend Butuh Database Connection Pooling?","kenapa-backend-butuh-database-connection-pooling","Pernah kena error Too many connections padahal CPU server masih santai di angka 30%? Masalahnya bukan di query kalian, tapi di cara aplikasi ngobrol sama database. Yuk, kenalan sama Connection Pooling!",[54,104,106,377,117,55],"connection-pooling",{"id":379,"title":380,"slug":381,"excerpt":382,"thumbnail_image":48,"tags":383},"33","Berkenalan dengan RabbitMQ: Si Kurir Pesan Serba Bisa","berkenalan-dengan-rabbitmq-si-kurir-pesan-serba-bisa","Pernah nggak sih kalian klik Bayar Sekarang dan notifikasi suksesnya muncul seketika, padahal email konfirmasi baru nyampe beberapa detik kemudian? Rahasianya ada di satu kurir tak terlihat. Yuk, kita kenalan sama RabbitMQ!",[342,283,54,168,343,384],"queue","\u003Cp>Kalau kamu pernah mampir ke forum pemrograman, kamu pasti pernah ketemu kalimat ini: &quot;mau aplikasi kencang? Jauhi bahasa ber-\u003Cem>GC\u003C/em> kayak Java, Go, C#, Python, atau \u003Cem>JavaScript\u003C/em>, pakai C, C++, atau Rust aja.&quot; Anggapan itu berumur panjang, dan di baliknya ada satu gambaran soal cara kerja GC yang perlu kita periksa.\u003C/p>\n\u003Cp>Ada benarnya, sih: GC emang beneran makan sumber daya, dan itu bukan hal yang bisa dibantah. Cuma, dua hal yang sering dianggap pasti soal GC—dia jalan tiap beberapa detik, dan dia selalu bikin lemot—lebih baik kamu lihat sendiri mekanismenya. Di \u003Ca href=\"https://invasikode.com/p/aplikasimu-lambat-dan-kamu-udah-kepikiran-ganti-bahasa-tunggu-dulu\">artikel sebelumnya\u003C/a> kita udah lihat Discord dan Cloudflare menghadapi batasan ini dengan mengukur dulu, bukan menebak. Sekarang waktunya ngintip batasan itu dari dalam, yuk. 🙂\u003C/p>\n\u003Ch2 id=\"gc-jalan-pakai-timer\">GC jalan pakai timer?\u003C/h2>\n\u003Cp>Sketsa paling gampang buat mbayangin cara kerja GC itu kira-kira begini:\u003C/p>\n\n\u003Cdiv class=\"code-block-wrapper my-6 not-prose rounded-xl border-2 border-black dark:border-gray-600 shadow-neo overflow-hidden bg-[#24292e] text-[#e1e4e8] transition-all\">\n  \u003Cdiv class=\"code-block-header flex items-center justify-between px-4 py-2.5 bg-[#1f2428] border-b-2 border-black dark:border-gray-600 font-mono text-xs font-bold text-gray-300 select-none\">\n    \u003Cdiv class=\"flex items-center gap-2\">\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#ff5f56] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#ffbd2e] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"w-3 h-3 rounded-full bg-[#27c93f] border border-black/40 inline-block\">\u003C/span>\n      \u003Cspan class=\"ml-2 font-mono font-bold text-xs uppercase tracking-wider text-gray-300\">TEXT\u003C/span>\n    \u003C/div>\n    \u003Cbutton type=\"button\" class=\"copy-code-btn flex items-center gap-1.5 px-3 py-1 text-xs font-bold bg-[#2f363d] text-gray-200 border-2 border-black dark:border-gray-500 rounded-lg shadow-neo-sm hover:translate-x-0.5 hover:translate-y-0.5 hover:shadow-none hover:bg-gray-700 transition-all cursor-pointer\" data-code=\"while%20true%3A%0A%20%20%20%20sleep(5)%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20tunggu%205%20detik%0A%20%20%20%20cari_objek_yang_udah_nggak_dipakai()\" title=\"Salin kode\">\n      \u003Csvg class=\"w-3.5 h-3.5 copy-icon-svg\" fill=\"none\" stroke=\"currentColor\" viewBox=\"0 0 24 24\">\n        \u003Cpath stroke-linecap=\"round\" stroke-linejoin=\"round\" stroke-width=\"2\" d=\"M8 16H6a2 2 0 01-2-2V6a2 2 0 012-2h8a2 2 0 012 2v2m-6 12h8a2 2 0 002-2v-8a2 2 0 00-2-2h-8a2 2 0 00-2 2v8a2 2 0 002 2z\">\u003C/path>\n      \u003C/svg>\n      \u003Cspan class=\"copy-text\">Copy\u003C/span>\n    \u003C/button>\n  \u003C/div>\n  \u003Cdiv class=\"code-block-content p-4 overflow-x-auto text-sm font-mono leading-relaxed bg-[#24292e]\">\n    \u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\">\u003Ccode>while true:\n    sleep(5)                        # tunggu 5 detik\n    cari_objek_yang_udah_nggak_dipakai()\u003C/code>\u003C/pre>\n  \u003C/div>\n\u003C/div>\u003Cp>Tapi bentuk aslinya tuh nggak kayak gitu. Kalau benar ada \u003Cem>timer\u003C/em> di situ, servermu yang nganggur di tengah malam bakal tetap sibuk memindai memori tiap lima detik: CPU-nya kebakar, tagihan \u003Cem>cloud\u003C/em>-nya naik, dan yang dibersihkan cuma kekosongan. Untungnya, GC modern nggak sedungu itu. 😅\u003C/p>\n\u003Cp>Yang dipakai hampir semua \u003Cem>runtime\u003C/em> modern sekarang adalah \u003Cstrong>ambang alokasi\u003C/strong>, bukan jam. GC cuma bangun kalau memori yang dialokasikan aplikasi nyentuh batas tertentu. Di Go, batas itu diatur lewat \u003Cem>environment variable\u003C/em> \u003Ccode>GOGC\u003C/code>, yang default-nya 100.\u003C/p>\n\u003Cp>Angka 100 itu artinya begini: GC membiarkan \u003Cem>heap\u003C/em> tumbuh sampai sekitar dua kali lipat memori hidup. Contohnya nih, kalau setelah satu siklus selesai memori yang masih hidup tinggal 10 MB, GC baru jalan lagi saat heap menyentuh 20 MB. Selama aplikasimu main di bawah angka itu, GC tidur nyenyak. Masuk akal kan?\u003C/p>\n\u003Cp>Angka 100-nya sendiri bisa kamu putar. Turunin ke 50, targetnya jadi sekitar 15 MB—GC lebih sering jalan, tapi RAM lebih hemat. Naikin ke 200, targetnya jadi sekitar 30 MB—GC lebih jarang jalan, tapi RAM lebih boros. Rumus lengkapnya ada di \u003Ca href=\"https://go.dev/doc/gc-guide\">panduan resmi GC Go\u003C/a> kalau kamu mau ngitung sendiri, tapi intinya cuma itu.\u003C/p>\n\u003Cp>Jadi jawabannya: nggak. GC nggak dijalankan pakai timer.\u003C/p>\n\u003Ch3 id=\"tapi-ada-juga-yang-memang-berbasis-waktu\">Tapi ada juga yang memang berbasis waktu\u003C/h3>\n\u003Cp>Di sinilah pertanyaannya jadi lebih menarik: beberapa \u003Cem>runtime\u003C/em> memang punya pemicu berbasis waktu. Go salah satunya. Dia \u003Cstrong>memaksa GC jalan minimal tiap 2 menit\u003C/strong>, terlepas dari seberapa lambat \u003Cem>heap\u003C/em>-nya tumbuh. Bukan gosip forum, itu ada sebagai \u003Ca href=\"https://go.googlesource.com/go/+/refs/heads/master/src/runtime/proc.go\">komentar di kode sumber Go\u003C/a>: kalau sudah 2 menit nggak ada koleksi, satu siklus dipaksa jalan.\u003C/p>\n\u003Cp>Kenapa sampai perlu? Karena ambang \u003Ccode>GOGC\u003C/code> cuma berguna kalau aplikasimu rajin mengalokasi. Kalau \u003Cem>live heap\u003C/em>-nya besar tapi alokasinya lambat—persis seperti Read States di Discord—ambang itu nggak pernah kesentuh, dan timer 2 menit inilah yang akhirnya ambil alih. Setiap kali dia jalan, GC harus memindai seluruh \u003Cem>LRU cache\u003C/em> yang isinya jutaan \u003Cem>user\u003C/em>. Dari situ \u003Ca href=\"https://discord.com/blog/why-discord-is-switching-from-go-to-rust\">blog Discord\u003C/a> sendiri nyimpulin kenapa grafik mereka punya \u003Cem>spike\u003C/em> yang datang rapi tiap sekitar 2 menit, dan kenapa usaha nge-\u003Cem>tuning\u003C/em> \u003Ccode>GC percent\u003C/code> gagal total.\u003C/p>\n\u003Cp>Go bukan satu-satunya. V8 di Chrome punya \u003Ca href=\"https://v8.dev/blog/free-garbage-collection\">\u003Cem>idle-time\u003C/em> GC\u003C/a>: kerja bersih-bersihnya dititipkan ke \u003Cem>idle task\u003C/em> yang dijadwalkan browser, bukan ke jadwal tetap. HotSpot malah menyediakan opsi \u003Ca href=\"https://openjdk.org/jeps/346\">\u003Ccode>G1PeriodicGCInterval\u003C/code>\u003C/a> yang memicu siklus GC berkala saat aplikasinya menganggur, biasanya buat balikin memori ke sistem operasi.\u003C/p>\n\u003Cp>Satu catatan jujur sebelum lanjut: kasus Discord itu terjadi di 2020, waktu Go masih di seri 1.8–1.10, dan cara kerja GC-nya sudah banyak berubah sejak itu. Yang nggak berubah: selama heap-mu gede dan isinya banyak \u003Cem>pointer\u003C/em>, memindainya tetap kerja yang harus dibayar. Perubahan itulah yang mendorong Go 1.19 menambah \u003Ccode>GOMEMLIMIT\u003C/code>, supaya kamu bisa nentuin batas memori absolut, bukan cuma rasio.\u003C/p>\n\u003Cp>Jadi kalau selama ini kamu mbayangin GC punya jadwal rutin, tebakanmu nggak ngawur. Yang bikin beda cuma porsinya: pemicu berbasis waktu itu jaring pengaman atau kerja sampingan, bukan mesin utamanya.\u003C/p>\n\u003Ch2 id=\"gc-itu-sebenarnya-ngapain-di-dalam\">GC itu sebenarnya ngapain di dalam?\u003C/h2>\n\u003Cp>GC tuh ibarat tukang bersih-bersih yang nggak keliling tiap jam: dia baru bergerak kalau ada yang memanggilnya. Dan hampir semua GC modern ikut keluarga \u003Cstrong>tracing\u003C/strong>, dengan pola dasar yang sama: \u003Cem>mark\u003C/em>, lalu \u003Cem>sweep\u003C/em>. Biar kebayang, kita bedah dua fase itu satu-satu.\u003C/p>\n\u003Ch3 id=\"gimana-gc-tahu-objek-mana-yang-masih-hidup\">Gimana GC tahu objek mana yang masih hidup?\u003C/h3>\n\u003Cp>GC nggak baca memori dari alamat nol secara buta. Dia mulai dari \u003Cstrong>GC roots\u003C/strong>: variabel lokal di \u003Cem>stack\u003C/em>, variabel global, dan register CPU. Dari situ dia jalan ngikutin \u003Cem>pointer\u003C/em> seperti menelusuri pohon. Objek yang kejangkau ditandai hidup. Setelah penelusuran selesai, heap disapu dan semua yang nggak ketandai dikembalikan ke daftar bebas, siap dipakai ulang tanpa minta alokasi baru ke sistem operasi.\u003C/p>\n\u003Cp>Satu detail yang sering kelewat: GC Go itu \u003Cem>non-moving\u003C/em>. Objeknya nggak digeser-geser di memori. Bahasa lain ada yang menggeser objeknya (\u003Cem>compacting\u003C/em>) supaya memori lebih rapat, tapi harganya semua \u003Cem>pointer\u003C/em> harus ikut diperbarui. Java dan V8 memilih jalan tengah dengan \u003Cstrong>generational\u003C/strong> \u003Cem>collector\u003C/em>, yang nebak bahwa objek muda lebih cepat mati, jadi nggak semua objek perlu diperiksa sama sering.\u003C/p>\n\u003Ch3 id=\"tracing-vs-menghitung-referensi\">Tracing vs menghitung referensi\u003C/h3>\n\u003Cp>Ada dua keluarga besar di sini. \u003Cem>Tracing\u003C/em> dipakai Go, Java, dan V8. \u003Cem>Reference counting\u003C/em> dipakai Python dan Swift, dengan cara yang beda: tiap objek nyimpen jumlah referensinya, dan begitu angkanya nol, memori langsung dibebaskan. Python bahkan pakai dua-duanya sekaligus, karena \u003Cem>refcount\u003C/em> sendirian nggak bisa ngurus objek yang saling tunjuk membentuk lingkaran.\u003C/p>\n\u003Cp>Pembagian ini penting buat diingat, soalnya dari sini kebijakan buat nge-\u003Cem>tune\u003C/em> GC jadi beda-beda: mulai dari \u003Ccode>GOGC\u003C/code> dan \u003Ccode>GOMEMLIMIT\u003C/code> di Go, pilihan \u003Cem>collector\u003C/em> G1 sampai ZGC di JVM, sampai pilihan buat mematikan sebagian GC di Python.\u003C/p>\n\u003Ch2 id=\"terus-biaya-performanya-di-mana\">Terus biaya performanya di mana?\u003C/h2>\n\u003Cp>Kalau algoritmanya cuma jalanin \u003Cem>pointer\u003C/em>, apa yang sebenarnya kita bayar? Tiga hal ini:\u003C/p>\n\u003Cul>\n\u003Cli>Jeda singkat di peralihan fase. Di Go, aplikasi cuma benar-benar berhenti (\u003Cem>stop-the-world\u003C/em>) sebentar aja di transisi antara \u003Cem>mark\u003C/em> dan \u003Cem>sweep\u003C/em>, dan panjangnya sengaja dibikin nggak tumbuh seiring ukuran \u003Cem>heap\u003C/em>. Di JVM, \u003Ca href=\"https://wiki.openjdk.org/display/zgc/Main\">ZGC\u003C/a> malah sudah jadi fitur produksi sejak JDK 15 dengan jeda sub-milidetik, bahkan di heap yang ukurannya bukan main.\u003C/li>\n\u003Cli>Porsi CPU yang disedot GC. Fase \u003Cem>mark\u003C/em> ngambil sekitar 25% CPU, dan itu artinya \u003Cem>thread\u003C/em> aplikasimu rebutan prosesor. Yang paling bikin kesel: kalau alokasimu cepat, goroutine-mu sendiri ikut ditarik buat bantu GC (\u003Cem>GC assist\u003C/em>).\u003C/li>\n\u003Cli>Overhead memori. \u003Ccode>GOGC=100\u003C/code> artinya kamu nyiapin ruang sekitar dua kali lipat memori hidup. Naikin \u003Ccode>GOGC\u003C/code>, GC jadi jarang jalan dan CPU lebih lega, tapi RAM lebih boros. Pasang \u003Ccode>GOMEMLIMIT\u003C/code> terlalu ketat, kamu dapat masalah baru bernama \u003Cem>thrashing\u003C/em>: GC jalan terus-terusan, dan aplikasi bisa melambat sampai dua kali lipat.\u003C/li>\n\u003C/ul>\n\u003Cp>Ada juga efek samping yang lebih susah diukur: metadata GC ikut memenuhi cache CPU, jadi data logika bisnismu terdepak ke RAM yang latensinya jauh lebih tinggi. Ini bukan angka yang keluar dari halaman dokumentasi mana pun, tapi masuk akal, dan Instagram sendiri nyebut soal naiknya \u003Cem>cache hit ratio\u003C/em> sebagai salah satu alasan mereka \u003Ca href=\"https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172\">mematikan GC di Python-nya\u003C/a>.\u003C/p>\n\u003Ch2 id=\"kapan-gc-beneran-jadi-masalah\">Kapan GC beneran jadi masalah?\u003C/h2>\n\u003Cp>Di sinilah keputusannya bisa dipertanggungjawabkan, dan jawabannya bergantung pada seberapa ketat tenggat waktumu.\u003C/p>\n\u003Cul>\n\u003Cli>Web API dan \u003Cem>microservice\u003C/em> biasa. Bukan masalah. Jeda setengah milidetik di \u003Cem>request\u003C/em> yang latensi jaringannya 30–50 ms nggak akan terasa siapa pun, dan sebagai gantinya kamu dapat bahasa yang bebas dari satu kelas \u003Cem>bug\u003C/em> paling mahal. Microsoft sendiri \u003Ca href=\"https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactive-approach-to-more-secure-code\">bilang sekitar 70% \u003Cem>CVE\u003C/em>\u003C/a> yang mereka perbaiki tiap tahun itu masalah \u003Cem>memory safety\u003C/em>, dan itu di kode C dan C++.\u003C/li>\n\u003Cli>Game yang ngejar 60 FPS atau lebih. Coba bayangin deh, di 60 FPS satu \u003Cem>frame\u003C/em> cuma punya 16,6 ms, dan di 144 FPS sisanya tinggal 6,9 ms. Jeda GC 10 ms aja udah cukup bikin \u003Cem>frame\u003C/em>-nya patah-patah.\u003C/li>\n\u003Cli>Kernel, \u003Cem>driver\u003C/em>, dan sistem \u003Cem>hard real-time\u003C/em>. Di sini yang penting bukan kecepatan rata-rata, tapi determinisme. Sistem yang cuma boleh telat mikrodetik nggak bisa nyerahin jadwalnya ke GC.\u003C/li>\n\u003Cli>\u003Cem>High-frequency trading\u003C/em>. Yang diperdagangkan di sini mikrodetik. Distribusi jeda yang nggak bisa ditebak sama mahalnya dengan jedanya sendiri.\u003C/li>\n\u003C/ul>\n\u003Cp>Lihat polanya: yang bikin GC jadi masalah bukan &quot;GC lambat&quot;, tapi &quot;GC nggak bisa dijadwalkan&quot;. Selama tenggat aplikasimu longgar, tuduhan itu jatuh dengan sendirinya.\u003C/p>\n\u003Ch2 id=\"jadi-gc-itu-masalah-atau-bukan\">Jadi, GC itu masalah atau bukan?\u003C/h2>\n\u003Cp>Buat sebagian besar software yang kamu bangun, jawabannya: bukan. GC menukar sedikit RAM dan sedikit CPU dengan hilangnya satu kelas \u003Cem>bug\u003C/em> paling mahal yang pernah ada di dunia C—dan itu Microsoft sendiri yang bilang, bukan penggemar Go.\u003C/p>\n\u003Cp>Instagram malah bisa mematikan \u003Cem>cyclic collector\u003C/em> di Python-nya dan langsung \u003Ca href=\"https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172\">jalan 10% lebih efisien\u003C/a> tanpa pindah bahasa. Tapi itu cuma masuk akal karena prosesnya berumur pendek dan sering di-\u003Cem>restart\u003C/em>.\u003C/p>\n\u003Cp>Jadi yang perlu kita lakukan bukan menghindari GC, tapi tahu kapan dia mulai kebebanan. Kalau grafik \u003Cem>latency\u003C/em>-mu punya \u003Cem>spike\u003C/em> rapi tiap beberapa menit, tersangkanya mungkin GC, dan kamu bahkan bisa nebak dari durasi \u003Cem>spike\u003C/em>-nya. Tapi buktikan dulu pakai \u003Cem>profiler\u003C/em>, jangan cuma dari perasaan.\u003C/p>\n\u003Cp>Selamat membedah grafik \u003Cem>latency\u003C/em>-mu, dan semoga tersangkanya bukan yang salah tangkap. 👋\u003C/p>\n","\u003Cp>Garbage Collector modern memicu dirinya sendiri lewat ambang alokasi, bukan timer, dan buat sebagian besar aplikasi cara itu justru menguntungkan.\u003C/p>\n\u003Cul>\n\u003Cli>Jeda GC di runtime modern seperti Go dan ZGC sudah sub-milidetik dan nggak tumbuh seiring ukuran heap, jadi tuduhan &quot;GC bikin lemot&quot; cuma benar di sistem yang tenggat waktunya mikrodetik.\u003C/li>\n\u003Cli>Harga memori dari GC itu nyata tapi bisa diputar: GOGC yang tinggi menghemat CPU dengan tambahan RAM, sementara GOMEMLIMIT yang terlalu ketat justru berujung thrashing.\u003C/li>\n\u003Cli>Yang bikin GC jadi masalah bukan kecepatannya, tapi ketidakmampuan menjadwalkan jedanya, jadi selama tenggat aplikasimu longgar tersangkanya salah tangkap.\u003C/li>\n\u003Cli>Kasus Instagram menunjukkan sebagian masalah GC bisa dibereskan lewat konfigurasi, dan itu pun cuma masuk akal kalau prosesnya memang berumur pendek.\u003C/li>\n\u003C/ul>\n",[388,390,392,394,396,398],{"id":86,"title":87,"slug":88,"excerpt":89,"thumbnail_image":48,"tags":389},[91,92,93,94,95],{"id":254,"title":255,"slug":256,"excerpt":257,"thumbnail_image":48,"tags":391},[54,55,56,91,117,259],{"id":49,"title":50,"slug":51,"excerpt":52,"thumbnail_image":48,"tags":393},[54,55,56,57,58,59],{"id":68,"title":69,"slug":70,"excerpt":71,"thumbnail_image":48,"tags":395},[73,74,75,76],{"id":78,"title":79,"slug":80,"excerpt":81,"thumbnail_image":48,"tags":397},[83,84,74,73],{"id":399,"title":400,"slug":401,"excerpt":402,"thumbnail_image":48,"tags":403},"104","Query-nya Tinggal 2, Tapi Response-nya Masih 1 Detik","query-tinggal-2-tapi-response-masih-1-detik","Endpoint feed yang cuma menampilkan 20 tulisan butuh satu detik, dan server database dihujani 41 query. Kamu kerjakan nasihat N+1 yang standar, query-nya turun jadi 2, dan latency-nya nggak bergerak. Ini versi \"apa adanya\" dari masalah itu, plus lab-nya.",[104,55,54],[405,409,413,416,419,422,425,428],{"text":406,"depth":407,"id":408},"GC jalan pakai timer?",2,"gc-jalan-pakai-timer",{"text":410,"depth":411,"id":412},"Tapi ada juga yang memang berbasis waktu",3,"tapi-ada-juga-yang-memang-berbasis-waktu",{"text":414,"depth":407,"id":415},"GC itu sebenarnya ngapain di dalam?","gc-itu-sebenarnya-ngapain-di-dalam",{"text":417,"depth":411,"id":418},"Gimana GC tahu objek mana yang masih hidup?","gimana-gc-tahu-objek-mana-yang-masih-hidup",{"text":420,"depth":411,"id":421},"Tracing vs menghitung referensi","tracing-vs-menghitung-referensi",{"text":423,"depth":407,"id":424},"Terus biaya performanya di mana?","terus-biaya-performanya-di-mana",{"text":426,"depth":407,"id":427},"Kapan GC beneran jadi masalah?","kapan-gc-beneran-jadi-masalah",{"text":429,"depth":407,"id":430},"Jadi, GC itu masalah atau bukan?","jadi-gc-itu-masalah-atau-bukan",1791516341423]