ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮೆಮೊರಿ ನಿರ್ವಹಣೆ, ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳು, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್ ಮತ್ತು ಮೆಮೊರಿ-ಸುರಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು. ಮೆಮೊರಿ ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯಲು ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಹೇಗೆ ನೆರವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಮೆಮೊರಿ ನಿರ್ವಹಣೆ: ದೃಢವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ರೆಫರೆನ್ಸ್ ಟೈಪ್ ಸುರಕ್ಷತೆಯನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳುವುದು
ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ವಿಶಾಲ ಭೂದೃಶ್ಯದಲ್ಲಿ, ದೃಢವಾದ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಅತ್ಯಂತ ಮುಖ್ಯ. ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸೂಪರ್‌ಸೆಟ್ ಆಗಿ, ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಮೂಲಕ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸ್ವಯಂಚಾಲಿತ ಮೆಮೊರಿ ನಿರ್ವಹಣೆಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದರೂ, ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರಬಲ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ನೀಡುತ್ತದೆ, ಅದು ರೆಫರೆನ್ಸ್ ಟೈಪ್ ಸುರಕ್ಷತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮೆಮೊರಿಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು, ವಿಶೇಷವಾಗಿ ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಅದೃಶ್ಯ ಮೆಮೊರಿ ಲೀಕ್‌ಗಳನ್ನು ತಪ್ಪಿಸಲು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ಕೇಲ್ ಅಥವಾ ಅದು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಜಾಗತಿಕ ಪರಿಸರವನ್ನು ಲೆಕ್ಕಿಸದೆ, ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕೋಡ್ ಬರೆಯಲು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
ಈ ಸಮಗ್ರ ಮಾರ್ಗದರ್ಶಿ ಮೆಮೊರಿ ನಿರ್ವಹಣೆಯಲ್ಲಿ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪಾತ್ರವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ. ನಾವು ಆಧಾರವಾಗಿರುವ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮೆಮೊರಿ ಮಾದರಿಯನ್ನು ಅನ್ವೇಷಿಸುತ್ತೇವೆ, ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್‌ನ ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡುತ್ತೇವೆ, ಸಾಮಾನ್ಯ ಮೆಮೊರಿ ಲೀಕ್ ಮಾದರಿಗಳನ್ನು ಗುರುತಿಸುತ್ತೇವೆ ಮತ್ತು, ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ಹೆಚ್ಚು ಮೆಮೊರಿ-ಪರಿಣಾಮಕಾರಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬರೆಯಲು ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಟೈಪ್ ಸುರಕ್ಷತಾ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಎತ್ತಿ ತೋರಿಸುತ್ತೇವೆ. ನೀವು ಜಾಗತಿಕ ವೆಬ್ ಸೇವೆಯನ್ನು, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಥವಾ ಡೆಸ್ಕ್‌ಟಾಪ್ ಯುಟಿಲಿಟಿಯನ್ನು ನಿರ್ಮಿಸುತ್ತಿರಲಿ, ಈ ಪರಿಕಲ್ಪನೆಗಳ ಬಗ್ಗೆ ದೃಢವಾದ ತಿಳುವಳಿಕೆ ಅಮೂಲ್ಯವಾಗಿರುತ್ತದೆ.
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮೆಮೊರಿ ಮಾದರಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು: ಅಡಿಪಾಯ
ಮೆಮೊರಿ ಸುರಕ್ಷತೆಗೆ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಕೊಡುಗೆಯನ್ನು ಪ್ರಶಂಸಿಸಲು, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಸ್ವತಃ ಮೆಮೊರಿಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಮೊದಲು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. C ಅಥವಾ C++ ನಂತಹ ಭಾಷೆಗಳಂತಲ್ಲದೆ, ಡೆವಲಪರ್‌ಗಳು ಮೆಮೊರಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹಂಚಿಕೆ ಮತ್ತು ಡಿಅಲೋಕೇಟ್ ಮಾಡುತ್ತಾರೆ, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಪರಿಸರಗಳು (Node.js ಅಥವಾ ವೆಬ್ ಬ್ರೌಸರ್‌ಗಳಂತಹವು) ಮೆಮೊರಿ ನಿರ್ವಹಣೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸುತ್ತವೆ. ಈ ಅಬ್ಸ್ಟ್ರಾಕ್ಷನ್ ಅಭಿವೃದ್ಧಿಯನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಆದರೆ ಅದರ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಜವಾಬ್ದಾರಿಯಿಂದ ನಮ್ಮನ್ನು ಮುಕ್ತಗೊಳಿಸುವುದಿಲ್ಲ, ವಿಶೇಷವಾಗಿ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ.
ಮೌಲ್ಯ ಪ್ರಕಾರಗಳು vs. ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳು
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮೆಮೊರಿ ಮಾದರಿಯಲ್ಲಿನ ಒಂದು ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಮೌಲ್ಯ ಪ್ರಕಾರಗಳು (ಪ್ರಿಮಿಟಿವ್ಸ್) ಮತ್ತು ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳು (ಆಬ್ಜೆಕ್ಟ್‌ಗಳು) ನಡುವೆ. ಈ ವ್ಯತ್ಯಾಸವು ಡೇಟಾವನ್ನು ಹೇಗೆ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ನಕಲು ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರವೇಶಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಮೆಮೊರಿ ನಿರ್ವಹಣೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಕೇಂದ್ರವಾಗಿದೆ.
- ಮೌಲ್ಯ ಪ್ರಕಾರಗಳು (ಪ್ರಿಮಿಟಿವ್ಸ್): ಇವು ಸರಳ ಡೇಟಾ ಪ್ರಕಾರಗಳಾಗಿವೆ, ಅಲ್ಲಿ ನಿಜವಾದ ಮೌಲ್ಯವನ್ನು ನೇರವಾಗಿ ವೇರಿಯಬಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ನೀವು ಒಂದು ಪ್ರಿಮಿಟಿವ್ ಮೌಲ್ಯವನ್ನು ಇನ್ನೊಂದು ವೇರಿಯಬಲ್‌ಗೆ ನಿಯೋಜಿಸಿದಾಗ, ಆ ಮೌಲ್ಯದ ನಕಲನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. ಒಂದು ವೇರಿಯಬಲ್‌ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳು ಇನ್ನೊಂದರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪ್ರಿಮಿಟಿವ್ ಪ್ರಕಾರಗಳಲ್ಲಿ `number`, `string`, `boolean`, `symbol`, `bigint`, `null`, ಮತ್ತು `undefined` ಸೇರಿವೆ.
- ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳು (ಆಬ್ಜೆಕ್ಟ್‌ಗಳು): ಇವು ಸಂಕೀರ್ಣ ಡೇಟಾ ಪ್ರಕಾರಗಳಾಗಿವೆ, ಅಲ್ಲಿ ವೇರಿಯಬಲ್ ನಿಜವಾದ ಡೇಟಾವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಮೆಮೊರಿಯಲ್ಲಿ ಡೇಟಾ (ಆಬ್ಜೆಕ್ಟ್) ಇರುವ ಸ್ಥಳಕ್ಕೆ ಒಂದು ರೆಫರೆನ್ಸ್ (ಒಂದು ಪಾಯಿಂಟರ್) ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ನೀವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಇನ್ನೊಂದು ವೇರಿಯಬಲ್‌ಗೆ ನಿಯೋಜಿಸಿದಾಗ, ಅದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ನಕಲು ಮಾಡುವುದಿಲ್ಲ, ಬದಲಿಗೆ ರೆಫರೆನ್ಸ್ ಅನ್ನು ನಕಲು ಮಾಡುತ್ತದೆ. ಈಗ ಎರಡೂ ವೇರಿಯಬಲ್‌ಗಳು ಮೆಮೊರಿಯಲ್ಲಿ ಒಂದೇ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಸೂಚಿಸುತ್ತವೆ. ಒಂದು ವೇರಿಯಬಲ್ ಮೂಲಕ ಮಾಡಿದ ಬದಲಾವಣೆಗಳು ಇನ್ನೊಂದರ ಮೂಲಕ ಗೋಚರಿಸುತ್ತವೆ. ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳಲ್ಲಿ `objects`, `arrays`, `functions`, ಮತ್ತು `classes` ಸೇರಿವೆ.
ಒಂದು ಸರಳ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಉದಾಹರಣೆಯೊಂದಿಗೆ ವಿವರಿಸೋಣ:
// Value Type Example
let a: number = 10;
let b: number = a; // 'b' gets a copy of 'a's value
b = 20; // Changing 'b' does not affect 'a'
console.log(a); // Output: 10
console.log(b); // Output: 20
// Reference Type Example
interface User {
id: number;
name: string;
}
let user1: User = { id: 1, name: "Alice" };
let user2: User = user1; // 'user2' gets a copy of 'user1's reference
user2.name = "Alicia"; // Changing 'user2's property also changes 'user1's property
console.log(user1.name); // Output: Alicia
console.log(user2.name); // Output: Alicia
let user3: User = { id: 1, name: "Alice" };
console.log(user1 === user3); // Output: false (different references, even if content is similar)
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಹೇಗೆ ಹಂಚಿಕೊಳ್ಳಲಾಗುತ್ತದೆ ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಹೇಗೆ ಬಳಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ವ್ಯತ್ಯಾಸವು ನಿರ್ಣಾಯಕವಾಗಿದೆ. ಇದನ್ನು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವುದರಿಂದ ಅನಿರೀಕ್ಷಿತ ಅಡ್ಡ ಪರಿಣಾಮಗಳು ಮತ್ತು, ಸಂಭಾವ್ಯವಾಗಿ, ಮೆಮೊರಿ ಲೀಕ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಕಾಲ್ ಸ್ಟಾಕ್ ಮತ್ತು ಹೀಪ್
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಎಂಜಿನ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಮೆಮೊರಿಯನ್ನು ಎರಡು ಪ್ರಾಥಮಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ ಆಯೋಜಿಸುತ್ತವೆ:
- ಕಾಲ್ ಸ್ಟಾಕ್: ಇದು ಕಾರ್ಯ ಕರೆ ಫ್ರೇಮ್‌ಗಳು, ಸ್ಥಳೀಯ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಪ್ರಿಮಿಟಿವ್ ಮೌಲ್ಯಗಳನ್ನು ಒಳಗೊಂಡಂತೆ ಸ್ಥಿರ ಡೇಟಾಗಾಗಿ ಬಳಸುವ ಮೆಮೊರಿ ಪ್ರದೇಶವಾಗಿದೆ. ಒಂದು ಕಾರ್ಯವನ್ನು ಕರೆದಾಗ, ಒಂದು ಹೊಸ ಫ್ರೇಮ್ ಅನ್ನು ಸ್ಟಾಕ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ. ಅದು ಹಿಂತಿರುಗಿದಾಗ, ಫ್ರೇಮ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ. ಇದು ವೇಗದ, ಸಂಘಟಿತ ಮೆಮೊರಿ ಪ್ರದೇಶವಾಗಿದೆ, ಅಲ್ಲಿ ಡೇಟಾವು ಉತ್ತಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಜೀವಿತಾವಧಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು (ಆಬ್ಜೆಕ್ಟ್‌ಗಳಲ್ಲ) ಸಹ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ.
- ಹೀಪ್: ಇದು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಇತರ ರೆಫರೆನ್ಸ್ ಪ್ರಕಾರಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸುವ ದೊಡ್ಡ, ಹೆಚ್ಚು ಕ್ರಿಯಾತ್ಮಕ ಮೆಮೊರಿ ಪ್ರದೇಶವಾಗಿದೆ. ಹೀಪ್‌ನಲ್ಲಿನ ಡೇಟಾವು ಕಡಿಮೆ ರಚನಾತ್ಮಕ ಜೀವಿತಾವಧಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ; ಇದನ್ನು ವಿವಿಧ ಸಮಯಗಳಲ್ಲಿ ಹಂಚಿಕೆ ಮತ್ತು ಡಿಅಲೋಕೇಟ್ ಮಾಡಬಹುದು. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್ ಪ್ರಾಥಮಿಕವಾಗಿ ಹೀಪ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರೋಗ್ರಾಂನ ಯಾವುದೇ ಭಾಗದಿಂದ ಇನ್ನು ಮುಂದೆ ಉಲ್ಲೇಖಿಸದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಂದ ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಮೆಮೊರಿಯನ್ನು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಮರುಪಡೆಯುತ್ತದೆ.
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸ್ವಯಂಚಾಲಿತ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ (GC)
ಪ್ರಸ್ತಾಪಿಸಿದಂತೆ, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಒಂದು ಗಾರ್ಬೇಜ್-ಕಲೆಕ್ಟೆಡ್ ಭಾಷೆಯಾಗಿದೆ. ಇದರರ್ಥ ಡೆವಲಪರ್‌ಗಳು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮುಗಿದ ನಂತರ ಮೆಮೊರಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಮುಕ್ತಗೊಳಿಸುವುದಿಲ್ಲ. ಬದಲಿಗೆ, ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಎಂಜಿನ್‌ನ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್, ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರೋಗ್ರಾಂನಿಂದ ಇನ್ನು ಮುಂದೆ "ತಲುಪಲಾಗದ" ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪತ್ತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅವು ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಮೆಮೊರಿಯನ್ನು ಮರುಪಡೆಯುತ್ತದೆ. ಈ ಅನುಕೂಲವು ಡಬಲ್-ಫ್ರೀಯಿಂಗ್ ಅಥವಾ ಮೆಮೊರಿಯನ್ನು ಮುಕ್ತಗೊಳಿಸಲು ಮರೆತುಹೋಗುವಂತಹ ಸಾಮಾನ್ಯ ಮೆಮೊರಿ ದೋಷಗಳನ್ನು ತಡೆಯುತ್ತದೆ, ಆದರೆ ಇದು ಬೇರೆ ರೀತಿಯ ಸವಾಲುಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ, ಮುಖ್ಯವಾಗಿ ಅನಗತ್ಯ ರೆಫರೆನ್ಸ್‌ಗಳು ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಜೀವಂತವಾಗಿ ಇಡುವುದನ್ನು ತಡೆಯುವ ಬಗ್ಗೆ.
GC ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ: ಮಾರ್ಕ್-ಅಂಡ್-ಸ್ವೀಪ್ ಅಲ್ಗಾರಿದಮ್
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ಗಳು (ಕ್ರೋಮ್ ಮತ್ತು Node.js ನಲ್ಲಿ ಬಳಸುವ V8 ಸೇರಿದಂತೆ) ಬಳಸುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಅಲ್ಗಾರಿದಮ್ ಮಾರ್ಕ್-ಅಂಡ್-ಸ್ವೀಪ್ ಅಲ್ಗಾರಿದಮ್ ಆಗಿದೆ. ಇದು ಎರಡು ಮುಖ್ಯ ಹಂತಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ:
- ಮಾರ್ಕ್ ಹಂತ: GC ಎಲ್ಲಾ "ರೂಟ್" ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ (ಉದಾ., `window` ಅಥವಾ `global` ನಂತಹ ಜಾಗತಿಕ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು, ಪ್ರಸ್ತುತ ಕಾಲ್ ಸ್ಟಾಕ್‌ನಲ್ಲಿನ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು). ನಂತರ ಅದು ಈ ರೂಟ್‌ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ ಆಬ್ಜೆಕ್ಟ್ ಗ್ರಾಫ್ ಅನ್ನು ಸಂಚರಿಸುತ್ತದೆ, ಅದು ತಲುಪಬಹುದಾದ ಪ್ರತಿಯೊಂದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಗುರುತಿಸುತ್ತದೆ. ರೂಟ್‌ನಿಂದ ತಲುಪಬಹುದಾದ ಯಾವುದೇ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು "ಜೀವಂತ" ಅಥವಾ ಬಳಕೆಯಲ್ಲಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
- ಸ್ವೀಪ್ ಹಂತ: ಗುರುತಿಸಿದ ನಂತರ, GC ಸಂಪೂರ್ಣ ಹೀಪ್ ಅನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಗುರುತಿಸದ ಯಾವುದೇ ಆಬ್ಜೆಕ್ಟ್ (ಅಂದರೆ ಅದು ಇನ್ನು ಮುಂದೆ ರೂಟ್‌ಗಳಿಂದ ತಲುಪಲಾಗುವುದಿಲ್ಲ) ಅನ್ನು "ಸತ್ತಿದೆ" ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಮೆಮೊರಿಯನ್ನು ಮರುಪಡೆಯಲಾಗುತ್ತದೆ. ಈ ಮೆಮೊರಿಯನ್ನು ನಂತರ ಹೊಸ ಹಂಚಿಕೆಗಳಿಗಾಗಿ ಬಳಸಬಹುದು.
ಆಧುನಿಕ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ಗಳು ಹೆಚ್ಚು ಅತ್ಯಾಧುನಿಕವಾಗಿವೆ. ಉದಾಹರಣೆಗೆ, V8 ಒಂದು ಜೆನೆರೇಶನಲ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಇದು ಹೀಪ್ ಅನ್ನು "ಯಂಗ್ ಜನರೇಶನ್" (ಹೊಸದಾಗಿ ಹಂಚಿಕೆ ಮಾಡಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ಜೀವಿತಾವಧಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ) ಮತ್ತು "ಓಲ್ಡ್ ಜನರೇಶನ್" (ಹಲವಾರು GC ಸೈಕಲ್‌ಗಳಿಂದ ಬದುಕುಳಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ) ಎಂದು ವಿಭಜಿಸುತ್ತದೆ. ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ಕಾರ್ಯಗತಗೊಳಿಸುವಲ್ಲಿ ವಿರಾಮಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಈ ವಿಭಿನ್ನ ಪ್ರದೇಶಗಳಿಗೆ ವಿಭಿನ್ನ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು (ಯಂಗ್ ಜನರೇಶನ್‌ಗೆ ಸ್ಕ್ಯಾವೆಂಜರ್ ಮತ್ತು ಓಲ್ಡ್ ಜನರೇಶನ್‌ಗೆ ಮಾರ್ಕ್-ಸ್ವೀಪ್-ಕಾಂಪ್ಯಾಕ್ಟ್ ನಂತಹ) ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗಿದೆ.
GC ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ನಿರ್ದಿಷ್ಟವಲ್ಲ. ಡೆವಲಪರ್‌ಗಳು ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಚೋದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಅಥವಾ ಅದು ಯಾವಾಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಎಂಜಿನ್‌ಗಳು GC ಅನ್ನು ಯಾವಾಗ ಚಲಾಯಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ವಿವಿಧ ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್‌ಗಳು ಮತ್ತು ಆಪ್ಟಿಮೈಸೇಶನ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಮೆಮೊರಿ ಬಳಕೆ ಕೆಲವು ಮಿತಿಗಳನ್ನು ದಾಟಿದಾಗ ಅಥವಾ ಕಡಿಮೆ CPU ಚಟುವಟಿಕೆಯ ಅವಧಿಗಳಲ್ಲಿ. ಈ ನಿರ್ದಿಷ್ಟವಲ್ಲದ ಸ್ವಭಾವವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ತಾರ್ಕಿಕವಾಗಿ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗಿದ್ದರೂ, ಎಂಜಿನ್‌ನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿ ಮತ್ತು ತಂತ್ರವನ್ನು ಅವಲಂಬಿಸಿ ಅದು ತಕ್ಷಣವೇ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾಗದಿರಬಹುದು ಎಂದರ್ಥ.
JS/TS ನಲ್ಲಿ "ಮೆಮೊರಿ ನಿರ್ವಹಣೆ" ಎಂಬ ಭ್ರಮೆ
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ, ಡೆವಲಪರ್‌ಗಳು ಮೆಮೊರಿ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ ಎಂಬುದು ಒಂದು ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆ. ಇದು ತಪ್ಪು. ಕೈಪಿಡಿ ಡಿಅಲೋಕೇಷನ್ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ, ಡೆವಲಪರ್‌ಗಳು ಇನ್ನೂ ಮೂಲಭೂತವಾಗಿ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ನಿಜವಾಗಿಯೂ ತಲುಪಲಾಗದಿದ್ದರೆ ಮಾತ್ರ GC ಮೆಮೊರಿಯನ್ನು ಮರುಪಡೆಯಬಹುದು. ನಿಮಗೆ ಅಜಾಗರೂಕತೆಯಿಂದ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ರೆಫರೆನ್ಸ್ ಅನ್ನು ನಿರ್ವಹಿಸಿದರೆ, GC ಅದನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಇದು ಮೆಮೊರಿ ಲೀಕ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ರೆಫರೆನ್ಸ್ ಟೈಪ್ ಸುರಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸುವಲ್ಲಿ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪಾತ್ರ
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಮೆಮೊರಿಯನ್ನು ನೇರವಾಗಿ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ; ಇದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಕಂಪೈಲ್ ಆಗುತ್ತದೆ, ಅದು ತನ್ನ ರನ್‌ಟೈಮ್ ಮೂಲಕ ಮೆಮೊರಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಶಕ್ತಿಯುತ ಸ್ಟಾಟಿಕ್ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಅಮೂಲ್ಯವಾದ ಸಾಧನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಅದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮೆಮೊರಿ-ಸಂಬಂಧಿತ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಡಿಮೆ ಗುರಿಯಾಗುವ ಕೋಡ್ ಬರೆಯಲು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ. ಟೈಪ್ ಸುರಕ್ಷತೆಯನ್ನು ಜಾರಿಗೊಳಿಸುವ ಮೂಲಕ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಕೋಡಿಂಗ್ ಮಾದರಿಗಳನ್ನು ಉತ್ತೇಜಿಸುವ ಮೂಲಕ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು, ಆಕಸ್ಮಿಕ ಬದಲಾವಣೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಜೀವಿತಾವಧಿಗಳನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.
`strictNullChecks` ನೊಂದಿಗೆ `undefined`/`null` ರೆಫರೆನ್ಸ್ ದೋಷಗಳನ್ನು ತಡೆಯುವುದು
ರನ್‌ಟೈಮ್ ಸುರಕ್ಷತೆಗೆ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಅತ್ಯಂತ ಮಹತ್ವದ ಕೊಡುಗೆಗಳಲ್ಲಿ ಒಂದು, ಮತ್ತು ಅದರಿಂದ ಮೆಮೊರಿ ಸುರಕ್ಷತೆಗೆ, `strictNullChecks` ಕಂಪೈಲರ್ ಆಯ್ಕೆಯಾಗಿದೆ. ಇದನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ, ಸಂಭಾವ್ಯ `null` ಅಥವಾ `undefined` ಮೌಲ್ಯಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ವಹಿಸಲು ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಮೌಲ್ಯದ ಮೇಲೆ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪ್ರಯತ್ನಿಸಿದಾಗ ಸಂಭವಿಸುವ ರನ್‌ಟೈಮ್ ದೋಷಗಳ (ಸಾಮಾನ್ಯವಾಗಿ "ಬಿಲಿಯನ್-ಡಾಲರ್ ತಪ್ಪುಗಳು" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ) ದೊಡ್ಡ ವರ್ಗವನ್ನು ತಡೆಯುತ್ತದೆ.
ಮೆಮೊರಿ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಿರ್ವಹಿಸದ `null` ಅಥವಾ `undefined` ಅನಿರೀಕ್ಷಿತ ಪ್ರೋಗ್ರಾಂ ನಡವಳಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು, ಸಂಭಾವ್ಯವಾಗಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಅಸಮಂಜಸ ಸ್ಥಿತಿಯಲ್ಲಿ ಇರಿಸಬಹುದು ಅಥವಾ ಸ್ವಚ್ಛಗೊಳಿಸುವ ಕಾರ್ಯವನ್ನು ಸರಿಯಾಗಿ ಕರೆಯದ ಕಾರಣ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ವಿಫಲವಾಗಬಹುದು. ಶೂನ್ಯತೆಯನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವ ಮೂಲಕ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಹೆಚ್ಚು ದೃಢವಾದ ಸ್ವಚ್ಛಗೊಳಿಸುವ ತರ್ಕವನ್ನು ಬರೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಯಾವಾಗಲೂ ನಿರೀಕ್ಷೆಯಂತೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.
interface UserProfile {
id: string;
email: string;
lastLogin?: Date; // Optional property, can be 'undefined'
}
function displayUserProfile(user: UserProfile) {
// Without strictNullChecks, accessing user.lastLogin.toISOString() directly
// could lead to a runtime error if lastLogin is undefined.
// With strictNullChecks, TypeScript forces handling:
if (user.lastLogin) {
console.log(`Last login: ${user.lastLogin.toISOString()}`);
} else {
console.log("User has never logged in.");
}
// Using optional chaining (ES2020+) is another safe way:
const loginDateString = user.lastLogin?.toISOString();
console.log(`Login date string (optional): ${loginDateString ?? 'N/A'}`);
}
let activeUser: UserProfile = { id: "user-123", email: "test@example.com", lastLogin: new Date() };
let newUser: UserProfile = { id: "user-456", email: "new@example.com" };
displayUserProfile(activeUser);
displayUserProfile(newUser);
ಶೂನ್ಯತೆಯ ಈ ಸ್ಪಷ್ಟ ನಿರ್ವಹಣೆಯು ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇರಿಸುವ ಅಥವಾ ರೆಫರೆನ್ಸ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ವಿಫಲವಾಗುವ ದೋಷಗಳ ಸಾಧ್ಯತೆಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರೋಗ್ರಾಂ ಹರಿವು ಹೆಚ್ಚು ಸ್ಪಷ್ಟ ಮತ್ತು ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದವಾಗಿರುತ್ತದೆ.
ಇಮ್ಮ್ಯೂಟಬಲ್ ಡೇಟಾ ರಚನೆಗಳು ಮತ್ತು `readonly`
ಇಮ್ಮ್ಯೂಟಬಿಲಿಟಿ ಒಂದು ವಿನ್ಯಾಸ ತತ್ವವಾಗಿದ್ದು, ಒಮ್ಮೆ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸಿದ ನಂತರ, ಅದನ್ನು ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಯಾವುದೇ "ಮಾರ್ಪಾಡು" ಹೊಸ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುವುದಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಸ್ಥಳೀಯವಾಗಿ ಆಳವಾದ ಇಮ್ಮ್ಯೂಟಬಿಲಿಟಿಯನ್ನು ಜಾರಿಗೊಳಿಸದಿದ್ದರೂ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ `readonly` ಮಾಡಿಫೈಯರ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಇದು ಕಂಪೈಲ್ ಸಮಯದಲ್ಲಿ ಆಳವಿಲ್ಲದ ಇಮ್ಮ್ಯೂಟಬಿಲಿಟಿಯನ್ನು ಜಾರಿಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಮೆಮೊರಿ ಸುರಕ್ಷತೆಗೆ ಇಮ್ಮ್ಯೂಟಬಿಲಿಟಿ ಏಕೆ ಉತ್ತಮವಾಗಿದೆ? ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಇಮ್ಮ್ಯೂಟಬಲ್ ಆಗಿರುವಾಗ, ಅವುಗಳ ಸ್ಥಿತಿ ಊಹಿಸಬಹುದಾದವಾಗಿರುತ್ತದೆ. ಅನಿರೀಕ್ಷಿತ ರೆಫರೆನ್ಸ್‌ಗಳು ಅಥವಾ ದೀರ್ಘಕಾಲದ ಆಬ್ಜೆಕ್ಟ್ ಜೀವಿತಾವಧಿಗಳಿಗೆ ಕಾರಣವಾಗುವ ಆಕಸ್ಮಿಕ ಬದಲಾವಣೆಗಳ ಅಪಾಯ ಕಡಿಮೆ ಇರುತ್ತದೆ. ಇದು ಡೇಟಾ ಹರಿವಿನ ಬಗ್ಗೆ ತಾರ್ಕಿಕವಾಗಿ ಸುಲಭವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಹಳೆಯ, ಮಾರ್ಪಡಿಸಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಉಳಿದಿರುವ ರೆಫರೆನ್ಸ್‌ನಿಂದ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ಆಕಸ್ಮಿಕವಾಗಿ ತಡೆಯುವ ದೋಷಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
interface Product {
readonly id: string;
readonly name: string;
price: number; // 'price' can be changed if not 'readonly'
}
const productA: Product = { id: "p001", name: "Laptop", price: 1200 };
// productA.id = "p002"; // Error: Cannot assign to 'id' because it is a read-only property.
productA.price = 1150; // This is allowed
// To create a "modified" product immutably:
const productB: Product = { ...productA, price: 1100, name: "Gaming Laptop" };
console.log(productA); // { id: 'p001', name: 'Laptop', price: 1150 }
console.log(productB); // { id: 'p001', name: 'Gaming Laptop', price: 1100 }
// productA and productB are distinct objects in memory.
`readonly` ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಮತ್ತು ಇಮ್ಮ್ಯೂಟಬಲ್ ಅಪ್‌ಡೇಟ್ ಮಾದರಿಗಳನ್ನು (ಆಬ್ಜೆಕ್ಟ್ ಸ್ಪ್ರೆಡ್ `...` ನಂತಹ) ಉತ್ತೇಜಿಸುವ ಮೂಲಕ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಹೊಸ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ರಚಿಸಿದಾಗ ಹಳೆಯ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಂದ ಮೆಮೊರಿಯನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಮರುಪಡೆಯಲು ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ಗೆ ಸುಲಭವಾಗುವ ಅಭ್ಯಾಸಗಳನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ.
ಸ್ಪಷ್ಟ ಮಾಲೀಕತ್ವ ಮತ್ತು ಸ್ಕೋಪ್ ಅನ್ನು ಜಾರಿಗೊಳಿಸುವುದು
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಬಲವಾದ ಟೈಪಿಂಗ್, ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ಮಾಡ್ಯೂಲ್ ಸಿಸ್ಟಮ್ ಸ್ವಾಭಾವಿಕವಾಗಿ ಉತ್ತಮ ಕೋಡ್ ಸಂಘಟನೆ ಮತ್ತು ಡೇಟಾ ರಚನೆಗಳು ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಮಾಲೀಕತ್ವದ ಸ್ಪಷ್ಟ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ. ಇದು ನೇರ ಮೆಮೊರಿ ನಿರ್ವಹಣಾ ಸಾಧನವಲ್ಲದಿದ್ದರೂ, ಈ ಸ್ಪಷ್ಟತೆಯು ಪರೋಕ್ಷವಾಗಿ ಮೆಮೊರಿ ಸುರಕ್ಷತೆಗೆ ಕೊಡುಗೆ ನೀಡುತ್ತದೆ:
- ಆಕಸ್ಮಿಕ ಜಾಗತಿಕ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು: ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮಾಡ್ಯೂಲ್ ಸಿಸ್ಟಮ್ (`import`/`export` ಅನ್ನು ಬಳಸುವುದು) ಒಂದು ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಘೋಷಿಸಲಾದ ವೇರಿಯಬಲ್‌ಗಳು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಆ ಮಾಡ್ಯೂಲ್‌ಗೆ ಸ್ಕೋಪ್ ಆಗಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಇದು ಅನಿಯಮಿತವಾಗಿ ಉಳಿಯುವ ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಆಕಸ್ಮಿಕ ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ರಚಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
- ಉತ್ತಮ ಆಬ್ಜೆಕ್ಟ್ ಜೀವಿತಾವಧಿಗಳು: ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗಾಗಿ ಇಂಟರ್‌ಫೇಸ್‌ಗಳು ಮತ್ತು ಪ್ರಕಾರಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ನಿರೀಕ್ಷಿತ ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ನಡವಳಿಕೆಗಳನ್ನು ಉತ್ತಮವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು, ಇದು ಈ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಹೆಚ್ಚು ಉದ್ದೇಶಪೂರ್ವಕ ರಚನೆ ಮತ್ತು ಅಂತಿಮ ಡಿರೆಫರೆನ್ಸಿಂಗ್ (GC ಗೆ ಅವಕಾಶ ನೀಡುವುದು) ಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಮೆಮೊರಿ ಲೀಕ್‌ಗಳು (ಮತ್ತು ಅವುಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು TS ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ)
ಸ್ವಯಂಚಾಲಿತ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಇದ್ದರೂ ಸಹ, ಮೆಮೊರಿ ಲೀಕ್‌ಗಳು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್/ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಮತ್ತು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಒಂದು ಪ್ರೋಗ್ರಾಂಗೆ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಅಜಾಗರೂಕತೆಯಿಂದ ಹಿಡಿದಿಟ್ಟುಕೊಂಡಾಗ ಮೆಮೊರಿ ಲೀಕ್ ಸಂಭವಿಸುತ್ತದೆ, ಇದು ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್ ಅವುಗಳ ಮೆಮೊರಿಯನ್ನು ಮರುಪಡೆಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಕಾಲಾನಂತರದಲ್ಲಿ, ಇದು ಹೆಚ್ಚಿದ ಮೆಮೊರಿ ಬಳಕೆ, ಕ್ಷೀಣಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕ್ರ್ಯಾಶ್‌ಗಳಿಗೂ ಕಾರಣವಾಗಬಹುದು. ಇಲ್ಲಿ, ನಾವು ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳನ್ನು ಮತ್ತು ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಚಿಂತನಶೀಲ ಬಳಕೆಯು ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ.
ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಆಕಸ್ಮಿಕ ಜಾಗತಿಕಗಳು
ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳು ಮೆಮೊರಿ ಲೀಕ್‌ಗಳಿಗೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಪಾಯಕಾರಿಯಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಪೂರ್ಣ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಉಳಿಯುತ್ತವೆ. ಒಂದು ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ದೊಡ್ಡ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ರೆಫರೆನ್ಸ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡರೆ, ಆ ಆಬ್ಜೆಕ್ಟ್ ಎಂದಿಗೂ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾಗುವುದಿಲ್ಲ. `let`, `const`, ಅಥವಾ `var` ಇಲ್ಲದೆ ಕಟ್ಟುನಿಟ್ಟಲ್ಲದ ಮೋಡ್ ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ, ಅಥವಾ ಮಾಡ್ಯೂಲ್ ಅಲ್ಲದ ಫೈಲ್‌ನಲ್ಲಿ ವೇರಿಯಬಲ್ ಅನ್ನು ಘೋಷಿಸಿದಾಗ ಆಕಸ್ಮಿಕ ಜಾಗತಿಕಗಳು ಸಂಭವಿಸಬಹುದು.
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಹೇಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ: ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮಾಡ್ಯೂಲ್ ಸಿಸ್ಟಮ್ (`import`/`export`) ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಸ್ಕೋಪ್ ಮಾಡುತ್ತದೆ, ಆಕಸ್ಮಿಕ ಜಾಗತಿಕಗಳ ಸಾಧ್ಯತೆಯನ್ನು ನಾಟಕೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದಲ್ಲದೆ, `let` ಮತ್ತು `const` (ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಉತ್ತೇಜಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಟ್ರಾನ್ಸ್‌ಪೈಲ್ ಮಾಡುತ್ತದೆ) ಅನ್ನು ಬಳಸುವುದರಿಂದ ಬ್ಲಾಕ್-ಸ್ಕೋಪಿಂಗ್ ಅನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಇದು `var` ನ ಫಂಕ್ಷನ್-ಸ್ಕೋಪಿಂಗ್‌ಗಿಂತ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿದೆ.
// Accidental Global (less common in modern TypeScript modules, but possible in plain JS)
// In a non-module JS file, 'data' would become global if 'var'/'let'/'const' is omitted
// data = { largeArray: Array(1000000).fill('some-data') };
// Correct approach in TypeScript modules:
// Declare variables within their tightest possible scope.
export function processData(input: string[]) {
const processedResults = input.map(item => item.toUpperCase());
// 'processedResults' is scoped to 'processData' and will be eligible for GC
// once the function finishes and no external references hold it.
return processedResults;
}
// If a global-like state is needed, manage its lifecycle carefully.
// e.g., using a singleton pattern or a carefully managed global service.
class GlobalCache {
private static instance: GlobalCache;
private cache: Map<string, any> = new Map();
private constructor() {}
public static getInstance(): GlobalCache {
if (!GlobalCache.instance) {
GlobalCache.instance = new GlobalCache();
}
return GlobalCache.instance;
}
public set(key: string, value: any) {
this.cache.set(key, value);
}
public get(key: string) {
return this.cache.get(key);
}
public clear() {
this.cache.clear(); // Important: provide a way to clear the cache
}
}
const myCache = GlobalCache.getInstance();
myCache.set("largeObject", { data: Array(1000000).fill('cached-data') });
// ... later, when no longer needed ...
// myCache.clear(); // Explicitly clear to allow GC
ಮುಚ್ಚದಿರುವ ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು ಮತ್ತು ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳು
ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು (ಉದಾ., DOM ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು, ಕಸ್ಟಮ್ ಈವೆಂಟ್ ಎಮಿಟರ್‌ಗಳು) ಮೆಮೊರಿ ಲೀಕ್‌ಗಳ ಒಂದು ಶಾಸ್ತ್ರೀಯ ಮೂಲವಾಗಿದೆ. ನೀವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ (ವಿಶೇಷವಾಗಿ DOM ಎಲಿಮೆಂಟ್‌ಗೆ) ಒಂದು ಈವೆಂಟ್ ಲಿಸನರ್ ಅನ್ನು ಲಗತ್ತಿಸಿದರೆ ಮತ್ತು ನಂತರ ಆ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು DOM ನಿಂದ ತೆಗೆದುಹಾಕಿದರೆ, ಆದರೆ ಲಿಸನರ್ ಅನ್ನು ತೆಗೆದುಹಾಕದಿದ್ದರೆ, ಲಿಸನರ್‌ನ ಕ್ಲೋಸರ್ ತೆಗೆದುಹಾಕಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ (ಮತ್ತು ಸಂಭಾವ್ಯವಾಗಿ ಅದರ ಪೋಷಕ ಸ್ಕೋಪ್‌ಗೆ) ರೆಫರೆನ್ಸ್ ಅನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಇದು ಆಬ್ಜೆಕ್ಟ್ ಮತ್ತು ಅದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಮೆಮೊರಿಯನ್ನು ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.
ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಒಳನೋಟ: ಘಟಕ ಅಥವಾ ಅವುಗಳನ್ನು ಹೊಂದಿಸಿದ ಆಬ್ಜೆಕ್ಟ್ ನಾಶವಾದಾಗ ಅಥವಾ ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು ಮತ್ತು ಚಂದಾದಾರಿಕೆಗಳನ್ನು ಸರಿಯಾಗಿ ಅನ್‌ಸಬ್‌ಸ್ಕ್ರೈಬ್ ಮಾಡಲಾಗಿದೆ ಅಥವಾ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಎಂದು ಯಾವಾಗಲೂ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಅನೇಕ UI ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು (ರಿಯಾಕ್ಟ್, ಆಂಗುಲರ್, ವೂ ನಂತಹವು) ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಲೈಫ್‌ಸೈಕಲ್ ಹುಕ್ಸ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ.
interface DOMElement extends EventTarget {
id: string;
innerText: string;
// Simplified for example
}
class ButtonComponent {
private buttonElement: DOMElement; // Assume this is a real DOM element
private clickHandler: () => void;
constructor(element: DOMElement) {
this.buttonElement = element;
this.clickHandler = () => {
console.log(`Button ${this.buttonElement.id} clicked!`);
// This closure implicitly captures 'this.buttonElement'
};
this.buttonElement.addEventListener("click", this.clickHandler);
}
// IMPORTANT: Clean up the event listener when the component is destroyed
public destroy() {
this.buttonElement.removeEventListener("click", this.clickHandler);
console.log(`Event listener for ${this.buttonElement.id} removed.`);
// Now, if 'this.buttonElement' is no longer referenced elsewhere,
// it can be garbage collected.
}
}
// Simulate a DOM element
const myButton: DOMElement = {
id: "submit-btn",
innerText: "Submit",
addEventListener: function(event: string, handler: Function) {
console.log(`Adding ${event} listener to ${this.id}`);
// In a real browser, this would attach to the actual element
},
removeEventListener: function(event: string, handler: Function) {
console.log(`Removing ${event} listener from ${this.id}`);
}
};
const component = new ButtonComponent(myButton);
// ... later, when the component is no longer needed ...
component.destroy();
// If 'myButton' isn't referenced elsewhere, it's now eligible for GC.
ಔಟರ್ ಸ್ಕೋಪ್ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಕ್ಲೋಸರ್‌ಗಳು
ಕ್ಲೋಸರ್‌ಗಳು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಪ್ರಬಲ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ, ಇದು ಒಳ ಕಾರ್ಯವು ತನ್ನ ಹೊರಗಿನ (ಲೆಕ್ಸಿಕಲ್) ಸ್ಕೋಪ್‌ನಿಂದ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಲು ಮತ್ತು ಪ್ರವೇಶಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಹೊರ ಕಾರ್ಯವು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ನಂತರವೂ ಸಹ. ಇದು ಅತ್ಯಂತ ಉಪಯುಕ್ತವಾಗಿದ್ದರೂ, ಒಂದು ಕ್ಲೋಸರ್ ಅನ್ನು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಜೀವಂತವಾಗಿ ಇರಿಸಿದರೆ ಮತ್ತು ಅದು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದ ದೊಡ್ಡ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ತನ್ನ ಹೊರಗಿನ ಸ್ಕೋಪ್‌ನಿಂದ ಸೆರೆಹಿಡಿದರೆ, ಈ ಕಾರ್ಯವಿಧಾನವು ಅಜಾಗರೂಕತೆಯಿಂದ ಮೆಮೊರಿ ಲೀಕ್‌ಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಒಳನೋಟ: ಒಂದು ಕ್ಲೋಸರ್ ಯಾವ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ಸೆರೆಹಿಡಿಯುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಗಮನವಿರಲಿ. ಒಂದು ಕ್ಲೋಸರ್ ದೀರ್ಘಕಾಲಿಕವಾಗಿರಬೇಕಾದರೆ, ಅದು ಅಗತ್ಯವಿರುವ, ಕನಿಷ್ಠ ಡೇಟಾವನ್ನು ಮಾತ್ರ ಸೆರೆಹಿಡಿಯುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
function createLargeDataProcessor(dataSize: number) {
const largeArray = Array(dataSize).fill({ value: "complex-object" }); // A large object
return function processAndLog() {
console.log(`Processing ${largeArray.length} items...`);
// ... imagine complex processing here ...
// This closure holds a reference to 'largeArray'
};
}
const processor = createLargeDataProcessor(1000000); // Creates a closure capturing a large array
// If 'processor' is held onto for a long time (e.g., as a global callback),
// 'largeArray' will not be garbage collected until 'processor' is.
// To allow GC, eventually dereference 'processor':
// processor = null; // Assuming no other references to 'processor' exist.
ಅನಿಯಂತ್ರಿತ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ ಕ್ಯಾಶ್‌ಗಳು ಮತ್ತು ಮ್ಯಾಪ್‌ಗಳು
ಸರಳ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ `Object`ಗಳು ಅಥವಾ `Map`ಗಳನ್ನು ಕ್ಯಾಶ್‌ಗಳಾಗಿ ಬಳಸುವುದು ಸಾಮಾನ್ಯ ಮಾದರಿಯಾಗಿದೆ. ಆದಾಗ್ಯೂ, ನೀವು ಅಂತಹ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಎಂದಿಗೂ ತೆಗೆದುಹಾಕದಿದ್ದರೆ, ಕ್ಯಾಶ್ ಅನಿಯಮಿತವಾಗಿ ಬೆಳೆಯಬಹುದು, ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್ ಸಂಗ್ರಹಿಸಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಬಳಸಿದ ಮೆಮೊರಿಯನ್ನು ಮರುಪಡೆಯುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಸಂಗ್ರಹಿಸಿದ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಸ್ವತಃ ದೊಡ್ಡದಾಗಿದ್ದರೆ ಅಥವಾ ಇತರ ದೊಡ್ಡ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ.
ಪರಿಹಾರ: `WeakMap` ಮತ್ತು `WeakSet` (ES6+)
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್, ES6 ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು, ಈ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರಗಳಾಗಿ `WeakMap` ಮತ್ತು `WeakSet` ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. `Map` ಮತ್ತು `Set` ಗಿಂತ ಭಿನ್ನವಾಗಿ, `WeakMap` ಮತ್ತು `WeakSet` ತಮ್ಮ ಕೀಗಳಿಗೆ (`WeakMap` ಗಾಗಿ) ಅಥವಾ ಅಂಶಗಳಿಗೆ (`WeakSet` ಗಾಗಿ) "ದುರ್ಬಲ" ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತವೆ. ದುರ್ಬಲ ರೆಫರೆನ್ಸ್ ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾಗುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಎಲ್ಲಾ ಇತರ ಬಲವಾದ ರೆಫರೆನ್ಸ್‌ಗಳು ಹೋಗಿದ್ದರೆ, ಅದನ್ನು ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ `WeakMap` ಅಥವಾ `WeakSet` ನಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
// Problematic Cache with `Map`:
const strongCache = new Map<any, any>();
let userObject = { id: 1, name: "John" };
strongCache.set(userObject, { data: "profile-info" });
userObject = null; // Dereferencing 'userObject'
// Even though 'userObject' is null, the entry in 'strongCache' still holds
// a strong reference to the original object, preventing its GC.
// console.log(strongCache.has({ id: 1, name: "John" })); // false (different object ref)
// console.log(strongCache.size); // Still 1
// Solution with `WeakMap`:
const weakCache = new WeakMap<object, any>(); // WeakMap keys must be objects
let userAccount = { id: 2, name: "Jane" };
weakCache.set(userAccount, { permission: "admin" });
console.log(weakCache.has(userAccount)); // Output: true
userAccount = null; // Dereferencing 'userAccount'
// Now, since there are no other strong references to the original userAccount object,
// it becomes eligible for GC. When it's collected, the entry in 'weakCache' will be
// automatically removed. (Cannot directly observe this with .has() immediately,
// as GC is non-deterministic, but it *will* happen).
// console.log(weakCache.has(userAccount)); // Output: false (after GC runs)
ನೀವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಲು ಬಯಸಿದಾಗ `WeakMap` ಅನ್ನು ಬಳಸಿ, ಆ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಬೇರೆಡೆ ಬಳಸದಿದ್ದರೆ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹಿಸುವುದನ್ನು ತಡೆಯದೆ. ಇದು ಮೆಮೊಯಿಜೇಶನ್, ಖಾಸಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಅಥವಾ ಬಾಹ್ಯವಾಗಿ ನಿರ್ವಹಿಸುವ ತಮ್ಮದೇ ಆದ ಜೀವಿತಾವಧಿಯನ್ನು ಹೊಂದಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಮೆಟಾಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಲು ಸೂಕ್ತವಾಗಿದೆ.
ಟೈಮರ್‌ಗಳು (setTimeout, setInterval) ತೆರವುಗೊಳಿಸಿಲ್ಲ
`setTimeout` ಮತ್ತು `setInterval` ಕಾರ್ಯಗಳು ಭವಿಷ್ಯದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಕೋಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸುತ್ತವೆ. ಈ ಟೈಮರ್‌ಗಳಿಗೆ ರವಾನಿಸಲಾದ ಕಾಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯಗಳು ತಮ್ಮ ಲೆಕ್ಸಿಕಲ್ ಪರಿಸರವನ್ನು ಸೆರೆಹಿಡಿಯುವ ಕ್ಲೋಸರ್‌ಗಳನ್ನು ರಚಿಸುತ್ತವೆ. ಒಂದು ಟೈಮರ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದರೆ ಮತ್ತು ಅದರ ಕಾಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ರೆಫರೆನ್ಸ್ ಅನ್ನು ಸೆರೆಹಿಡಿದರೆ, ಮತ್ತು ಟೈಮರ್ ಅನ್ನು ಎಂದಿಗೂ ತೆರವುಗೊಳಿಸದಿದ್ದರೆ (`clearTimeout` ಅಥವಾ `clearInterval` ಅನ್ನು ಬಳಸಿ), ಆ ಆಬ್ಜೆಕ್ಟ್ (ಮತ್ತು ಅದರ ಸೆರೆಹಿಡಿದ ಸ್ಕೋಪ್) ಸಕ್ರಿಯ UI ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಹರಿವಿನ ಭಾಗವಾಗಿಲ್ಲದಿದ್ದರೂ ಸಹ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಮೆಮೊರಿಯಲ್ಲಿ ಉಳಿಯುತ್ತದೆ.
ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಒಳನೋಟ: ಅವುಗಳನ್ನು ರಚಿಸಿದ ಘಟಕ ಅಥವಾ ಸಂದರ್ಭವು ಇನ್ನು ಮುಂದೆ ಸಕ್ರಿಯವಾಗಿಲ್ಲದಿದ್ದಾಗ ಯಾವಾಗಲೂ ಟೈಮರ್‌ಗಳನ್ನು ತೆರವುಗೊಳಿಸಿ. `setTimeout`/`setInterval` ನಿಂದ ಹಿಂದಿರುಗಿದ ಟೈಮರ್ ID ಅನ್ನು ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ಬಳಸಿ.
class DataUpdater {
private intervalId: number | null = null;
private data: string[] = [];
constructor(initialData: string[]) {
this.data = [...initialData];
}
public startUpdating() {
if (this.intervalId === null) {
this.intervalId = setInterval(() => {
this.data.push(`New item ${new Date().toLocaleTimeString()}`);
console.log(`Data updated: ${this.data.length} items`);
// This closure holds a reference to 'this.data'
}, 1000) as unknown as number; // Type assertion for setInterval return
}
}
public stopUpdating() {
if (this.intervalId !== null) {
clearInterval(this.intervalId);
this.intervalId = null;
console.log("Data updater stopped.");
}
}
public getData(): readonly string[] {
return this.data;
}
}
const updater = new DataUpdater(["Initial Item"]);
updater.startUpdating();
// After some time, when the updater is no longer needed:
// setTimeout(() => {
// updater.stopUpdating();
// // If 'updater' is no longer referenced anywhere, it's now eligible for GC.
// }, 5000);
// If updater.stopUpdating() is never called, the interval will run forever,
// and the DataUpdater instance (and its 'data' array) will never be GC'd.
ಮೆಮೊರಿ-ಸುರಕ್ಷಿತ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು
ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಮೆಮೊರಿ ಮಾದರಿಯ ತಿಳುವಳಿಕೆಯನ್ನು ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಮತ್ತು ಶ್ರದ್ಧೆಯಿಂದ ಕೋಡಿಂಗ್ ಅಭ್ಯಾಸಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸುವುದು ಮೆಮೊರಿ-ಸುರಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬರೆಯಲು ಪ್ರಮುಖವಾಗಿದೆ. ಇಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳಿವೆ:
- `strictNullChecks` ಮತ್ತು `noUncheckedIndexedAccess` ಅನ್ನು ಸ್ವೀಕರಿಸಿ: ಈ ನಿರ್ಣಾಯಕ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಕಂಪೈಲರ್ ಆಯ್ಕೆಗಳನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿ. `strictNullChecks` ನೀವು `null` ಮತ್ತು `undefined` ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ವಹಿಸುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ರನ್‌ಟೈಮ್ ದೋಷಗಳನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ರೆಫರೆನ್ಸ್ ನಿರ್ವಹಣೆಯನ್ನು ಉತ್ತೇಜಿಸುತ್ತದೆ. `noUncheckedIndexedAccess` ಸಂಭಾವ್ಯವಾಗಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸೂಚ್ಯಂಕಗಳಲ್ಲಿ ಅರೇ ಅಂಶಗಳನ್ನು ಅಥವಾ ಆಬ್ಜೆಕ್ಟ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪ್ರವೇಶಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು `undefined` ಮೌಲ್ಯಗಳನ್ನು ತಪ್ಪಾಗಿ ಬಳಸಲು ಕಾರಣವಾಗಬಹುದು.
- `var` ಬದಲಿಗೆ `const` ಮತ್ತು `let` ಅನ್ನು ಆದ್ಯತೆ ನೀಡಿ: ತಮ್ಮ ರೆಫರೆನ್ಸ್‌ಗಳು ಬದಲಾಗಬಾರದ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ ಯಾವಾಗಲೂ `const` ಅನ್ನು ಬಳಸಿ, ಮತ್ತು ತಮ್ಮ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಬಹುದಾದ ವೇರಿಯಬಲ್‌ಗಳಿಗೆ `let` ಅನ್ನು ಬಳಸಿ. `var` ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಪ್ಪಿಸಿ. ಇದು ಆಕಸ್ಮಿಕ ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ವೇರಿಯಬಲ್ ಸ್ಕೋಪ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ರೆಫರೆನ್ಸ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ GC ಗೆ ಗುರುತಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
- ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು ಮತ್ತು ಚಂದಾದಾರಿಕೆಗಳನ್ನು ಶ್ರದ್ಧೆಯಿಂದ ನಿರ್ವಹಿಸಿ: ಪ್ರತಿ `addEventListener` ಅಥವಾ ಚಂದಾದಾರಿಕೆಗೆ, ಅನುಗುಣವಾದ `removeEventListener` ಅಥವಾ `unsubscribe` ಕರೆ ಇದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಆಧುನಿಕ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಅಂತರ್ನಿರ್ಮಿತ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು (ಉದಾ., ರಿಯಾಕ್ಟ್‌ನಲ್ಲಿ `useEffect` ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ, ಆಂಗುಲರ್‌ನಲ್ಲಿ `ngOnDestroy`) ಒದಗಿಸುತ್ತವೆ. ಕಸ್ಟಮ್ ಈವೆಂಟ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗಾಗಿ, ಸ್ಪಷ್ಟವಾದ ಅನ್‌ಸಬ್‌ಸ್ಕ್ರೈಬ್ ಮಾದರಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.
- ಆಬ್ಜೆಕ್ಟ್-ಕೀಡ್ ಕ್ಯಾಶ್‌ಗಳಿಗಾಗಿ `WeakMap` ಮತ್ತು `WeakSet` ಅನ್ನು ಬಳಸಿ: ಕೀಲಿಯನ್ನು ಆಬ್ಜೆಕ್ಟ್ ಆಗಿರುವ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವಾಗ ಮತ್ತು ಕ್ಯಾಶ್ ಆಬ್ಜೆಕ್ಟ್ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾಗುವುದನ್ನು ತಡೆಯಲು ನೀವು ಬಯಸದಿದ್ದಾಗ, `WeakMap` ಅನ್ನು ಬಳಸಿ. ಅಂತೆಯೇ, `WeakSet` ಬಲವಾದ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳದೆ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಉಪಯುಕ್ತವಾಗಿದೆ.
- ಟೈಮರ್‌ಗಳನ್ನು ಧಾರ್ಮಿಕವಾಗಿ ತೆರವುಗೊಳಿಸಿ: ಪ್ರತಿ `setTimeout` ಮತ್ತು `setInterval` ಗೆ ಅನುಗುಣವಾದ `clearTimeout` ಅಥವಾ `clearInterval` ಕರೆ ಇರಬೇಕು, ಕಾರ್ಯಾಚರಣೆಯು ಇನ್ನು ಮುಂದೆ ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಅಥವಾ ಅದಕ್ಕೆ ಜವಾಬ್ದಾರಿಯುತ ಘಟಕವು ನಾಶವಾದಾಗ.
- ಇಮ್ಮ್ಯೂಟಬಿಲಿಟಿ ಮಾದರಿಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳಿ: ಸಾಧ್ಯವಿರುವಲ್ಲೆಲ್ಲಾ, ಡೇಟಾವನ್ನು ಇಮ್ಮ್ಯೂಟಬಲ್ ಆಗಿ ಪರಿಗಣಿಸಿ. ಗುಣಲಕ್ಷಣಗಳು ಮತ್ತು ಅರೇ ಪ್ರಕಾರಗಳಿಗೆ (`readonly string[]`) ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನ `readonly` ಮಾಡಿಫೈಯರ್ ಅನ್ನು ಬಳಸಿ. ನವೀಕರಣಗಳಿಗಾಗಿ, ಸ್ಪ್ರೆಡ್ ಆಪರೇಟರ್ (`{ ...obj, prop: newValue }`) ನಂತಹ ತಂತ್ರಗಳನ್ನು ಅಥವಾ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವವುಗಳನ್ನು ಮಾರ್ಪಡಿಸುವ ಬದಲು ಹೊಸ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು/ಅರೇಗಳನ್ನು ರಚಿಸಲು ಇಮ್ಮ್ಯೂಟಬಲ್ ಡೇಟಾ ಲೈಬ್ರರಿಗಳನ್ನು ಬಳಸಿ. ಇದು ಡೇಟಾ ಹರಿವು ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಜೀವಿತಾವಧಿಗಳ ಬಗ್ಗೆ ತಾರ್ಕಿಕವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತದೆ.
- ಜಾಗತಿಕ ಸ್ಥಿತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ: ದೊಡ್ಡ ಡೇಟಾ ರಚನೆಗಳನ್ನು ದೀರ್ಘಕಾಲದವರೆಗೆ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗಳು ಅಥವಾ ಸಿಂಗಲ್ಟನ್ ಸೇವೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ. ಘಟಕಗಳು ಅಥವಾ ಮಾಡ್ಯೂಲ್‌ಗಳಲ್ಲಿ ಸ್ಥಿತಿಯನ್ನು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡಿ, ಅವುಗಳು ಇನ್ನು ಮುಂದೆ ಬಳಕೆಯಲ್ಲಿಲ್ಲದಿದ್ದಾಗ ಅವುಗಳ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.
- ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಪ್ರೊಫೈಲ್ ಮಾಡಿ: ಮೆಮೊರಿ ಲೀಕ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಡೀಬಗ್ ಮಾಡಲು ಅತ್ಯಂತ ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವೆಂದರೆ ಪ್ರೊಫೈಲಿಂಗ್ ಮೂಲಕ. ಬ್ರೌಸರ್ ಡೆವಲಪರ್ ಪರಿಕರಗಳನ್ನು (ಉದಾ., ಹೀಪ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು ಮತ್ತು ಅಲೋಕೇಶನ್ ಟೈಮ್‌ಲೈನ್‌ಗಳಿಗಾಗಿ ಕ್ರೋಮ್‌ನ ಮೆಮೊರಿ ಟ್ಯಾಬ್) ಅಥವಾ Node.js ಪ್ರೊಫೈಲಿಂಗ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿ. ನಿಯಮಿತ ಪ್ರೊಫೈಲಿಂಗ್, ವಿಶೇಷವಾಗಿ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ಗುಪ್ತ ಮೆಮೊರಿ ಧಾರಣ ಸಮಸ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು.
- ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮಾಡ್ಯೂಲರೈಸ್ ಮಾಡಿ ಮತ್ತು ಸ್ಕೋಪ್ ಮಾಡಿ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಣ್ಣ, ಕೇಂದ್ರೀಕೃತ ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾರ್ಯಗಳಾಗಿ ವಿಭಜಿಸಿ. ಇದು ಸ್ವಾಭಾವಿಕವಾಗಿ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಸ್ಕೋಪ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಅವುಗಳು ಇನ್ನು ಮುಂದೆ ತಲುಪಲಾಗದಿದ್ದಾಗ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ಗೆ ನಿರ್ಧರಿಸುವುದನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
- ಲೈಬ್ರರಿ/ಫ್ರೇಮ್‌ವರ್ಕ್ ಲೈಫ್‌ಸೈಕಲ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ: ನೀವು UI ಫ್ರೇಮ್‌ವರ್ಕ್ (ಉದಾ., ಆಂಗುಲರ್, ರಿಯಾಕ್ಟ್, ವೂ) ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಅದರ ಲೈಫ್‌ಸೈಕಲ್ ಹುಕ್ಸ್‌ಗಳನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ. ಘಟಕಗಳನ್ನು ರಚಿಸಿದಾಗ, ನವೀಕರಿಸಿದಾಗ ಅಥವಾ ನಾಶಪಡಿಸಿದಾಗ ಸಂಪನ್ಮೂಲಗಳನ್ನು (ಚಂದಾದಾರಿಕೆಗಳು, ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳು ಮತ್ತು ಇತರ ರೆಫರೆನ್ಸ್‌ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದು ಸೇರಿದಂತೆ) ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಲು ಈ ಹುಕ್ಸ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಇವುಗಳನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಥವಾ ನಿರ್ಲಕ್ಷಿಸುವುದು ಸೋರಿಕೆಗಳ ಪ್ರಮುಖ ಮೂಲವಾಗಬಹುದು.
ಮೆಮೊರಿ ಡೀಬಗ್ ಮಾಡಲು ಸುಧಾರಿತ ಪರಿಕಲ್ಪನೆಗಳು ಮತ್ತು ಪರಿಕರಗಳು
ನಿರಂತರ ಮೆಮೊರಿ ಸಮಸ್ಯೆಗಳು ಅಥವಾ ಹೆಚ್ಚು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ, ಡೀಬಗ್ ಮಾಡುವ ಪರಿಕರಗಳು ಮತ್ತು ಸುಧಾರಿತ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ವೈಶಿಷ್ಟ್ಯಗಳ ಆಳವಾದ ಅಧ್ಯಯನವು ಕೆಲವೊಮ್ಮೆ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
-
ಕ್ರೋಮ್ ಡೆವ್‌ಟೂಲ್ಸ್ ಮೆಮೊರಿ ಟ್ಯಾಬ್: ಇದು ಫ್ರಂಟ್-ಎಂಡ್ ಮೆಮೊರಿ ಡೀಬಗ್ ಮಾಡಲು ನಿಮ್ಮ ಪ್ರಾಥಮಿಕ ಅಸ್ತ್ರವಾಗಿದೆ.
- ಹೀಪ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳು: ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೆಮೊರಿಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಅನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ. ಬೇರ್ಪಟ್ಟ DOM ಅಂಶಗಳು, ಉಳಿಸಿಕೊಂಡಿರುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ಗುರುತಿಸಲು ಎರಡು ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ಗಳನ್ನು (ಉದಾ., ಸೋರಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದಾದ ಕ್ರಿಯೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ) ಹೋಲಿಕೆ ಮಾಡಿ.
- ಅಲೋಕೇಶನ್ ಟೈಮ್‌ಲೈನ್‌ಗಳು: ಕಾಲಾನಂತರದಲ್ಲಿ ಹಂಚಿಕೆಗಳನ್ನು ದಾಖಲಿಸಿ. ಇದು ಮೆಮೊರಿ ಸ್ಪೈಕ್‌ಗಳನ್ನು ದೃಶ್ಯೀಕರಿಸಲು ಮತ್ತು ಹೊಸ ಆಬ್ಜೆಕ್ಟ್ ರಚನೆಗೆ ಕಾರಣವಾದ ಕಾಲ್ ಸ್ಟಾಕ್‌ಗಳನ್ನು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದು ಅತಿಯಾದ ಮೆಮೊರಿ ಹಂಚಿಕೆಯ ಪ್ರದೇಶಗಳನ್ನು ಗುರುತಿಸಬಹುದು.
- ರಿಟೈನರ್‌ಗಳು: ಹೀಪ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್‌ನಲ್ಲಿನ ಯಾವುದೇ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ, ಅದನ್ನು ಉಲ್ಲೇಖಿಸುವ ಇತರ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ನೋಡಲು ಅದರ "ರಿಟೈನರ್‌ಗಳನ್ನು" ನೀವು ಪರಿಶೀಲಿಸಬಹುದು, ಇದು ಅದರ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ. ಸೋರಿಕೆಯ ಮೂಲ ಕಾರಣವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಇದು ಅಮೂಲ್ಯವಾಗಿದೆ.
- Node.js ಮೆಮೊರಿ ಪ್ರೊಫೈಲಿಂಗ್: Node.js ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬ್ಯಾಕ್-ಎಂಡ್ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ, ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ವಿಶ್ಲೇಷಿಸಲು ಮತ್ತು ಸೋರಿಕೆಗಳನ್ನು ಗುರುತಿಸಲು ಕ್ರೋಮ್ ಡೆವ್‌ಟೂಲ್ಸ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿ `node --inspect` ನಂತಹ ಅಂತರ್ನಿರ್ಮಿತ ಪರಿಕರಗಳನ್ನು ಅಥವಾ `heapdump` ಅಥವಾ `clinic doctor` ನಂತಹ ಮೀಸಲಾದ npm ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. V8 ಎಂಜಿನ್‌ನ ಮೆಮೊರಿ ಫ್ಲಾಗ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಹ ಆಳವಾದ ಒಳನೋಟಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
-
`WeakRef` ಮತ್ತು `FinalizationRegistry` (ES2021+): ಇವು ಸುಧಾರಿತ, ಪ್ರಾಯೋಗಿಕ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ವೈಶಿಷ್ಟ್ಯಗಳಾಗಿವೆ, ಇದು ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಹೆಚ್ಚು ಸ್ಪಷ್ಟವಾದ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ, ಆದರೂ ಗಮನಾರ್ಹ ಎಚ್ಚರಿಕೆಗಳೊಂದಿಗೆ.
- `WeakRef`: ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ದುರ್ಬಲ ರೆಫರೆನ್ಸ್ ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ರೆಫರೆನ್ಸ್ ಆಬ್ಜೆಕ್ಟ್ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾಗುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, `WeakRef` ಅನ್ನು ಡಿರೆಫರೆನ್ಸ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುವುದು `undefined` ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಇದು ಕ್ಯಾಶ್‌ಗಳನ್ನು ಅಥವಾ ದೊಡ್ಡ ಡೇಟಾ ರಚನೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಉಪಯುಕ್ತವಾಗಿದೆ, ಅಲ್ಲಿ ನೀವು ಆಬ್ಜೆಕ್ಟ್‌ಗಳೊಂದಿಗೆ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ, ಅವುಗಳ ಜೀವಿತಾವಧಿಯನ್ನು ವಿಸ್ತರಿಸದೆ. ಆದಾಗ್ಯೂ, GC ಯ ನಿರ್ದಿಷ್ಟವಲ್ಲದ ಸ್ವಭಾವದಿಂದಾಗಿ `WeakRef` ಅನ್ನು ಸರಿಯಾಗಿ ಬಳಸಲು ಕುಖ್ಯಾತವಾಗಿ ಕಷ್ಟ.
- `FinalizationRegistry`: ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಗಾರ್ಬೇಜ್ ಸಂಗ್ರಹವಾದಾಗ ಕರೆಯಲಾಗುವ ಕಾಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವನ್ನು ನೋಂದಾಯಿಸಲು ಒಂದು ಕಾರ್ಯವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದನ್ನು ಸ್ಪಷ್ಟ ಸಂಪನ್ಮೂಲ ಶುದ್ಧೀಕರಣಕ್ಕಾಗಿ (ಉದಾ., ಫೈಲ್ ಹ್ಯಾಂಡಲ್ ಅನ್ನು ಮುಚ್ಚುವುದು, ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದು) ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಇನ್ನು ಮುಂದೆ ತಲುಪಲಾಗದ ನಂತರ ಬಳಸಬಹುದು. `WeakRef` ನಂತೆ, ಇದು ಸಂಕೀರ್ಣವಾಗಿದೆ, ಮತ್ತು ಸಮಯದ ಅನಿರೀಕ್ಷಿತತೆ ಮತ್ತು ಸೂಕ್ಷ್ಮ ದೋಷಗಳ ಸಾಮರ್ಥ್ಯದಿಂದಾಗಿ ಸಾಮಾನ್ಯ ಸನ್ನಿವೇಶಗಳಿಗೆ ಇದರ ಬಳಕೆಯನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ನಿರುತ್ಸಾಹಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ `WeakRef` ಮತ್ತು `FinalizationRegistry` ವಿರಳವಾಗಿ ಅಗತ್ಯವಿದೆ ಎಂದು ಒತ್ತಿಹೇಳುವುದು ಮುಖ್ಯ. ಡೆವಲಪರ್‌ಗೆ ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಮೆಮೊರಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದನ್ನು ತಡೆಯಲು ಸಂಪೂರ್ಣವಾಗಿ ಅಗತ್ಯವಿರುವ ನಿರ್ದಿಷ್ಟ ಸನ್ನಿವೇಶಗಳಿಗೆ ಅವು ಕಡಿಮೆ-ಮಟ್ಟದ ಪರಿಕರಗಳಾಗಿವೆ, ಆದರೆ ಅದರ ಅಂತಿಮ ಅವನತಿಗೆ ಸಂಬಂಧಿಸಿದ ಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಇನ್ನೂ ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಲೀಕ್ ಸಮಸ್ಯೆಗಳನ್ನು ಮೇಲೆ ವಿವರಿಸಿದ ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪರಿಹರಿಸಬಹುದು.
ತೀರ್ಮಾನ: ಮೆಮೊರಿ ಸುರಕ್ಷತೆಯಲ್ಲಿ ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಒಂದು ಮಿತ್ರನಾಗಿ
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನ ಸ್ವಯಂಚಾಲಿತ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ಅನ್ನು ಮೂಲಭೂತವಾಗಿ ಬದಲಾಯಿಸದಿದ್ದರೂ, ಅದರ ಸ್ಟಾಟಿಕ್ ಟೈಪ್ ಸಿಸ್ಟಮ್ ಮೆಮೊರಿ-ಸುರಕ್ಷಿತ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬರೆಯುವಲ್ಲಿ ಪ್ರಬಲ ಮಿತ್ರನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಟೈಪ್ ನಿರ್ಬಂಧಗಳನ್ನು ಜಾರಿಗೊಳಿಸುವ ಮೂಲಕ, ಸ್ಪಷ್ಟವಾದ ಕೋಡ್ ರಚನೆಗಳನ್ನು ಉತ್ತೇಜಿಸುವ ಮೂಲಕ ಮತ್ತು ಕಂಪೈಲ್ ಸಮಯದಲ್ಲಿ ಸಂಭಾವ್ಯ `null`/`undefined` ಸಮಸ್ಯೆಗಳನ್ನು ಹಿಡಿಯಲು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುವ ಮೂಲಕ, ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್ ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಟರ್‌ನೊಂದಿಗೆ ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಹಕರಿಸುವ ಮಾದರಿಗಳ ಕಡೆಗೆ ನಿಮ್ಮನ್ನು ಕರೆದೊಯ್ಯುತ್ತದೆ.
ಟೈಪ್‌ಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ರೆಫರೆನ್ಸ್ ಟೈಪ್ ಸುರಕ್ಷತೆಯನ್ನು ಕರಗತ ಮಾಡಿಕೊಳ್ಳುವುದು ಗಾರ್ಬೇಜ್ ಕಲೆಕ್ಷನ್ ತಜ್ಞರಾಗುವುದಲ್ಲ; ಇದು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮೆಮೊರಿಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಮೂಲ ತತ್ವಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಬ್ಜೆಕ್ಟ್ ಧಾರಣವನ್ನು ತಡೆಯುವ ಕೋಡಿಂಗ್ ಅಭ್ಯಾಸಗಳನ್ನು ಅನ್ವಯಿಸುವುದು. `strictNullChecks` ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ನಿಮ್ಮ ಈವೆಂಟ್ ಲಿಸನರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ, ಕ್ಯಾಶ್‌ಗಳಿಗಾಗಿ `WeakMap` ನಂತಹ ಸೂಕ್ತ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಬಳಸಿ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಶ್ರದ್ಧೆಯಿಂದ ಪ್ರೊಫೈಲ್ ಮಾಡಿ. ಹಾಗೆ ಮಾಡುವುದರಿಂದ, ನೀವು ಕಾಲದ ಪರೀಕ್ಷೆಯನ್ನು ಮತ್ತು ಸ್ಕೇಲ್ ಅನ್ನು ಎದುರಿಸುವ ದೃಢವಾದ, ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತೀರಿ, ಅವುಗಳ ದಕ್ಷತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯೊಂದಿಗೆ ಜಗತ್ತಿನಾದ್ಯಂತದ ಬಳಕೆದಾರರನ್ನು ಸಂತೋಷಪಡಿಸುತ್ತೀರಿ.