Java ක්ලවුඩ්-නේටිව් මයික්රෝසේවාවල වේගවත් ආරම්භයක් ගැන අද කතා කරමු. 2026 වන විට “scale‑to‑zero” ආකෘතිය ජනප්රිය වූ අතර, Project CRaC (Coordinated Restore at Checkpoint) දැන් sub‑millisecond ආරම්භය සඳහා මූලික තාක්ෂණයක් බවට පත්වී ඇත.
CRaC එකේ මූලික අදහස, ක්රියාත්මක JVM එකේ තත්ත්වය “checkpoint” කර, අවශ්ය වේලාවක “restore” කිරීමයි. නමුත්, සරලව “snapshot” එකක් ගන්නා විට, විවෘත ෆයිල්, socket, thread වැනි සම්පත් පරීක්ෂා නොකරන්නේ නම්, නිශ්ශබ්ද පරිසරයක “restore” අසාර්ථක වන අවස්ථා බොහොමයක් සිදුවේ.
ඇයි මෙය වැදගත්? සම්පත් ලීක් (resource leak) නිසා CRaC runtime එක CheckpointException දෝෂයක් දාලා “freeze” ක්රියාව අත්හිටුවයි. උදාහරණයක් ලෙස, database connection pool එකක් “active” තත්ත්වයේම තිබුනොත් TCP socket එක අතුරුදන් නොවී, “restore” පසු deadlock හෝ අසම්පූර්ණ state එකක් ඇති කරයි.
JDK 26 නව native JFR (Java Flight Recorder) events සමඟ, මෙම ගැටලුව විශ්ලේෂණය කිරීම ඉතා පහසුයි. jdk.Checkpoint සහ jdk.Restore events භාවිතා කර, freeze කාලය, කුමන class එකක් වගකීම් බාධා කරයි කියා නිශ්චිතව හඳුනාගත හැක.
ආදර්ශ ක්රමයක් ලෙස, org.crac.Resource අතුරුමුහුණත (interface) නිර්මාණය කර, beforeCheckpoint සහ afterRestore ක්රියාකාරකම් idempotent (පනස්වරක් ක්රියාත්මක කළත් ගැටලුවක් නොවන) ලෙස ලියන්න. මෙයින්, checkpoint පසු සක්රිය HTTP ඉල්ලීම් අවසන් කර, විවෘත file descriptor ගණන අඩු කර, පද්ධතියේ ස්ථායීත්වය රැකගත හැක.
ශ්රී ලංකාවට ඇති වැදගත්කම
- ඉන්ටර්නෙට් සම්බන්ධතා අඩු වෙමින්, ලාංකීය startups ගෙන් cloud‑native microservices නිර්මාණය කිරීමේදී startup time කාලය මිලි-සෙකන්ඩ් පමණට අඩු කර, පාරිභෝගික අත්දැකීම වැඩි වේ.
- JDK 26 JFR events භාවිතයෙන් සම්පත් ලීක් හඳුනා ගැනීම, ශ්රී ලංකාවේ developers ලාට performance tuning ඉගෙන ගැනීමට නව අවස්ථා සලසයි.
- ආයතනික පද්ධතිවල reliability වැඩිවීම, banking, e‑commerce වැනි ක්ෂේත්රවල downtime අවම කර, ආර්ථිකයට ඵලදායීත්වය ලබා දේ.
අවසන් වශයෙන්, CRaC භාවිතා කරන සැම Java developer කෙනෙකුම, සම්පත් පරිපාලන hooks සකස් කරන විට idempotency සහ JFR event logging අත්යවශ්ය බව මතක තබා ගන්න. මෙයින් “restore” අසාර්ථකත්වයන් තොරව, cloud‑native යෙදුම්වල අධික කාර්යක්ෂමතාව ලබා ගත හැක.
