Strong Reference (শক্তিশালী রেফারেন্স): এটি কী, কাজের প্রক্রিয়া এবং ARC

Strong Reference কী?

Strong Reference একটি অবজেক্টের এমন এক ধরনের রেফারেন্স যা আবর্জনা সংগ্রহকারী বা মেমোরি ম্যানেজমেন্ট সিস্টেম দ্বারা এর ধ্বংস রোধ করে। যতক্ষণ অবজেক্টে কমপক্ষে একটি শক্তিশালী রেফারেন্স বিদ্যমান, ততক্ষণ এর মেমোরি মুক্ত হয় না। এটি মৌলিক প্রক্রিয়া যার উপর Swift এবং Objective-C-তে ARC এবং Java ও Kotlin-এ আবর্জনা সংগ্রহ ভিত্তিক।

শক্তিশালী রেফারেন্সের ধারণা স্বয়ংক্রিয় মেমোরি ম্যানেজমেন্ট সহ সমস্ত ভাষার জন্য মৌলিক। ARC সিস্টেমে, প্রতিটি শক্তিশালী রেফারেন্স অবজেক্টের রেফারেন্স কাউন্টার বাড়ায়। কাউন্টার শূন্য হলে, অবজেক্ট অবিলম্বে ডিলোকেট হয়। Java এবং Kotlin-এ আবর্জনা সংগ্রহ সহ, শক্তিশালী রেফারেন্স নিশ্চিত করে যে অবজেক্ট পৌঁছানো যায় এবং GC দ্বারা সংগ্রহ করা হবে না।

WWDC 2021 অনুসারে, iOS অ্যাপ্লিকেশনে প্রায় 35% মেমোরি লিক শক্তিশালী রেফারেন্সের ভুল ব্যবহার এবং retain cycles-এর সাথে সম্পর্কিত। Android ডেভেলপমেন্টে, closures এবং callbacks-এ অন্তর্নিহিত শক্তিশালী রেফারেন্সের মাধ্যমে লিক Context Leak-এর পরে মেমোরি সমস্যার দ্বিতীয় সবচেয়ে সাধারণ কারণ।

মেমোরির সাথে কার্যকরভাবে কাজ করার জন্য, আপনাকে strong, weak এবং unowned রেফারেন্সের মধ্যে পার্থক্য বুঝতে হবে এবং মালিকানা এবং অবজেক্টের জীবনকালের উপর ভিত্তি করে সঠিক রেফারেন্স প্রকার নির্বাচন করতে হবে।

ARC কীভাবে মেমোরি ম্যানেজমেন্ট পরিবর্তন করেছে

ARC-এর আগে, ডেভেলপাররা প্রতিটি অবজেক্টের জন্য ম্যানুয়ালি retain এবং release কল করতেন, যা অনেক ত্রুটির সৃষ্টি করত। ARC, যা Apple 2011 সালে LLVM 3.0-এর সাথে চালু করেছিল, কম্পাইল সময়ে মালিকানা গ্রাফ বিশ্লেষণ করে এই প্রক্রিয়াটি স্বয়ংক্রিয় করে। কম্পাইলার নিজেই প্রয়োজনীয় স্থানে retain, release এবং autorelease কল সন্নিবেশ করে।

Clang Static Analyzer অনুসারে, ARC চালু করা iOS অ্যাপ্লিকেশনে মেমোরি-সম্পর্কিত বাগ 70% কমিয়েছে। ডেভেলপারদের জন্য, এর অর্থ মেমোরি ম্যানেজমেন্ট নিরাপদ হয়েছে, কিন্তু একই সাথে বুঝতে হবে যে শক্তিশালী রেফারেন্সগুলি অভ্যন্তরীণভাবে কীভাবে কাজ করে — retain cycles এড়াতে।

Kotlin এবং Java-তে, আবর্জনা সংগ্রহকারী ARC-এর ভূমিকা পালন করে, কিন্তু শক্তিশালী রেফারেন্সের নীতি একই থাকে: GC Roots হল প্রবেশ বিন্দু যার মাধ্যমে অবজেক্টগুলি শক্তিশালী রেফারেন্স দ্বারা ধরে রাখা হয়। যতক্ষণ একটি অবজেক্ট GC Root থেকে শক্তিশালী রেফারেন্সের শৃঙ্খলের মাধ্যমে পৌঁছানো যায়, ততক্ষণ এটি সংগ্রহ করা হবে না।

ARC-তে Strong Reference কীভাবে কাজ করে?

ARC (Automatic Reference Counting) heap-এ প্রতিটি অবজেক্টের জন্য রেফারেন্স গণনা করে কাজ করে। যখন একটি অবজেক্টে নতুন শক্তিশালী রেফারেন্স তৈরি হয়, কাউন্টার বাড়ে (retain)। যখন রেফারেন্স ধ্বংস বা ওভাররাইট হয়, কাউন্টার কমে (release)। যখন কাউন্টার শূন্যে পৌঁছায়, অবজেক্ট অবিলম্বে মেমোরি থেকে সরানো হয়।

Swift-এ একটি উদাহরণ বিবেচনা করুন। যখন একটি ক্লাসের ইনস্ট্যান্স তৈরি হয়, ARC মেমোরি বরাদ্দ করে এবং retain count 1 সেট করে। অন্য ভেরিয়েবলে প্রতিটি নতুন অ্যাসাইনমেন্ট কাউন্টার বাড়ায়। যখন ভেরিয়েবল স্কোপের বাইরে যায়, কাউন্টার কমে:

class ProfileViewController {
    var nameLabel: String?
    var avatarImage: UIImage?

    func loadProfile() {
        // retain count = 1 নতুন ইনস্ট্যান্সের জন্য
        let user = User(name: "Ivan")
        // retain count = 2 nameLabel অ্যাসাইন করার পরে
        nameLabel = user.name
        // পদ্ধতি থেকে প্রস্থান — user স্কোপের বাইরে, retain count = 1
    }
}

এই কোডে, ARC নিশ্চিত করে যে User অবজেক্ট মেমোরিতে ততক্ষণ থাকে যতক্ষণ এটিতে কমপক্ষে একটি শক্তিশালী রেফারেন্স নির্দেশ করে। যখন loadProfile ফাংশন শেষ হয়, লোকাল user ভেরিয়েবল ধ্বংস হয়, কিন্তু nameLabel এখনও অবজেক্ট ধরে রাখে। মেমোরি কেবল তখনই মুক্ত হবে যখন nameLabel-এর অস্তিত্ব শেষ হবে বা এটি ওভাররাইট হবে।

Kotlin-এ, অনুরূপ আচরণ GC Roots-এর মাধ্যমে প্রদান করা হয়। যতক্ষণ আবর্জনা সংগ্রহকারী মূল (যেমন একটি স্ট্যাটিক ফিল্ড বা সক্রিয় থ্রেড) থেকে শক্তিশালী রেফারেন্সের একটি সনাক্তযোগ্য শৃঙ্খল বিদ্যমান, অবজেক্ট মেমোরিতে থাকে। পার্থক্য হল GC তাৎক্ষণিকভাবে মেমোরি মুক্ত করে না — এটি পৌঁছানোর বিশ্লেষণের পরে অ্যাসিঙ্ক্রোনাসভাবে ঘটে।

কখন মেমোরি মুক্তি ঘটে

ARC-তে, কাউন্টার শূন্যে পৌঁছালে মুক্তি সিঙ্ক্রোনাসভাবে ঘটে। Swift এবং Objective-C-তে, আপনি ঠিক জানেন কখন অবজেক্ট সরানো হবে। Kotlin এবং Java-তে, মুক্তির মুহূর্ত অপ্রত্যাশিত, কিন্তু এটি আবর্জনা সংগ্রহকারী স্তরে চক্রীয় নির্ভরতা সনাক্ত করার আরও নমনীয় স্কিম দ্বারা ক্ষতিপূরণ দেওয়া হয়।

Retain Cycles এবং মেমোরি লিক

Retain cycle (ধারণ চক্র) — এমন একটি পরিস্থিতি যেখানে দুই বা ততোধিক অবজেক্টের একে অপরের প্রতি পারস্পরিক শক্তিশালী রেফারেন্স থাকে। ফলস্বরূপ, তাদের retain count কখনও শূন্য হয় না এবং মেমোরি কখনও মুক্ত হয় না, এমনকি অবজেক্টগুলি অ্যাপ্লিকেশনের জন্য প্রয়োজনীয় না হওয়ার পরও।

একটি ক্লাসিক উদাহরণ: একটি প্যারেন্ট ভিউ কন্ট্রোলার একটি শক্তিশালী রেফারেন্সের সাথে চাইল্ড অবজেক্ট ধরে রাখে, এবং এটি পাল্টায় একটি শক্তিশালী রেফারেন্সের সাথে প্যারেন্ট ধরে রাখে। এটি ডেলিগেট, closures এবং নেস্টেড lambda এক্সপ্রেশন সহ পরিস্থিতিতে সাধারণ। Instruments Leaks অনুসারে, ARC ব্যবহার করে অ্যাপ্লিকেশনে সমস্ত মেমোরি লিকের 60% পর্যন্ত retain cycles হয়।

class ParentViewController: UIViewController {
    var child: ChildViewController?

    func setupChild() {
        child = ChildViewController()
        // retain cycle: প্যারেন্ট child ধরে রাখে, child closure-এর মাধ্যমে প্যারেন্ট ধরে রাখে
        child?.onEvent = {
            self.handleEvent()
        }
    }

    func handleEvent() {}
}

এখানে সমস্যা হল onEvent closure একটি শক্তিশালী রেফারেন্সের সাথে self (ParentViewController) ক্যাপচার করে, এবং ParentViewController নিজেই একটি শক্তিশালী রেফারেন্সের সাথে child ধরে রাখে। উভয় অবজেক্ট কখনও মুক্ত হবে না। সমাধান হল চক্র ভাঙতে closure-এ weak self ব্যবহার করা।

Kotlin-এ, বাহ্যিক অবজেক্ট ক্যাপচার করে এমন lambda ব্যবহার করলে অনুরূপ চক্র তৈরি হয়। JVM আবর্জনা সংগ্রহকারী সময়ের সাথে সাথে এই ধরনের চক্র সনাক্ত করতে পারে, কিন্তু কেবল যদি অবজেক্টগুলি GC Roots থেকে অপ্রাপ্য হয়। যদি চক্রটি সক্রিয় থ্রেড বা UI প্রসঙ্গের সাথে যুক্ত থাকে, তবে লিক পুরো অ্যাপ্লিকেশন জীবনকাল ধরে থাকে।

Strong vs Weak vs Unowned Reference

রেফারেন্স প্রকারের মধ্যে পার্থক্য বোঝা নিরাপদ মেমোরি ম্যানেজমেন্টের চাবিকাঠি। Strong Reference retain count বাড়ায়। Weak Reference retain count বাড়ায় না এবং অবজেক্ট ডিলোকেট হলে স্বয়ংক্রিয়ভাবে nil হয়। Unowned Reference ও retain count বাড়ায় না কিন্তু শূন্য হয় না — ডিলোকেশনের পরে এটি অ্যাক্সেস করলে ক্র্যাশ হয়।

রেফারেন্স প্রকারের পছন্দ মালিকানা সম্পর্ক দ্বারা নির্ধারিত হয়। যদি অবজেক্ট B, A-এর অংশ হয় এবং এটি ছাড়া থাকতে না পারে — Strong ব্যবহার করুন। যদি B স্বাধীনভাবে থাকতে পারে এবং বিজ্ঞপ্তির জন্য A-কে রেফারেন্স করে — Weak ব্যবহার করুন। Unowned খুব কমই ব্যবহৃত হয় — কেবল যখন চাইল্ড অবজেক্টের জীবনকাল প্যারেন্টের জীবনকাল অতিক্রম করে না।

ব্যবহারিক নির্বাচনের নিয়ম

Apple Developer Documentation সুপারিশ করে: ডিফল্টরূপে, সমস্ত মালিকানা সম্পর্কের জন্য strong ব্যবহার করুন। যদি retain cycle এড়াতে প্রয়োজন হয় — নির্ধারণ করুন কোন রেফারেন্স দুর্বল হওয়া উচিত। সাধারণত এটি শ্রেণিবিন্যাসের বিপরীত রেফারেন্স (চাইল্ড → প্যারেন্ট)। Kotlin-এ, অনুরূপ ভূমিকা java.lang.ref-এর WeakReference পালন করে, যা ক্যাশ এবং observer প্যাটার্নের জন্য ব্যবহৃত হয়।

শক্তিশালী রেফারেন্স সমস্যা কীভাবে ঠিক করবেন

Retain cycles সনাক্ত করা প্রথম পদক্ষেপ। দ্বিতীয়টি সেগুলি সঠিকভাবে নির্মূল করা। শক্তিশালী রেফারেন্স চক্র ভাঙার প্রধান হাতিয়ার হল একটি রেফারেন্সকে weak বা unowned দিয়ে প্রতিস্থাপন করা। আবর্জনা সংগ্রহ সহ ভাষায়, প্রতিটি অ্যাক্সেসের আগে ম্যানুয়াল null পরীক্ষা সহ WeakReference অতিরিক্তভাবে ব্যবহৃত হয়।

Swift এবং Objective-C-তে, সবচেয়ে সাধারণ সমাধান হল closures-এ [weak self] যোগ করা। এটি নিশ্চিত করে যে closure ডিলোকেশনের পরে অবজেক্ট ধরে রাখে না। Kotlin-এ, অনুরূপ উদ্দেশ্যে WeakReference র্যাপার বা onDestroy-এ স্পষ্ট রেফারেন্স পরিষ্কার করা ব্যবহার করা হয়।

class NetworkService {
    func fetchData(completion: @escaping (Data?) -> Void) {
        // weak self-এর মাধ্যমে ক্যাপচার — retain cycle বাদ দেওয়া হয়েছে
        URLSession.shared.dataTask(
            with: URL(string: "https://api.example.com")!
        ) { [weak self] data, response, error in
            guard let self else { return }
            completion(data)
        }.resume()
    }
}

এই উদাহরণে, [weak self] নিশ্চিত করে যে NetworkService আর প্রয়োজন না হওয়ার পরে closure দ্বারা ধরে রাখা না হয়। যদি অনুরোধ সম্পূর্ণ হওয়ার আগে self ডিলোকেট হয় — guard let self else { return } completion কল না করেই closure থেকে বেরিয়ে আসে।

Retain cycles নির্ণয়ের জন্য, iOS-এর জন্য Instruments Leaks বা Android-এর জন্য Android Profiler + LeakCanary ব্যবহার করুন। এই সরঞ্জামগুলি সঠিক ধারণ গ্রাফ দেখায় এবং নির্দেশ করে কোন শক্তিশালী রেফারেন্স অবজেক্ট মুক্তিতে বাধা দিচ্ছে। নিয়মিত মেমোরি প্রোফাইলিং যেকোনো মোবাইল প্রকল্পের CI/CD পাইপলাইনের অংশ হওয়া উচিত।

Swift এবং Kotlin-এ Strong Reference — তুলনা

Swift এবং Kotlin মৌলিকভাবে ভিন্ন মেমোরি ম্যানেজমেন্ট প্রক্রিয়া ব্যবহার করে, কিন্তু শক্তিশালী রেফারেন্সের ধারণা উভয়েই বিদ্যমান। Swift retain count = 0-এ সিঙ্ক্রোনাস মুক্তির সাথে ARC ব্যবহার করে। Kotlin একটি ট্রেসিং GC ব্যবহার করে যা অপ্রাপ্য অবজেক্ট অ্যাসিঙ্ক্রোনাসভাবে পরিষ্কার করে।

প্রধান ব্যবহারিক পার্থক্য: Swift-এ, retain cycle একটি নিশ্চিত লিক। Kotlin-এ, GC চক্র ভাঙতে পারে যদি অবজেক্টগুলি মূল থেকে অপ্রাপ্য হয়, কিন্তু লিক হওয়া অবজেক্টের জীবনকাল অপ্রত্যাশিত থাকে। তাই, উভয় ভাষায়, সর্বোত্তম কৌশল হল ডিজাইন পর্যায়ে শক্তিশালী রেফারেন্স চক্র এড়ানো।

Swift-এর জন্য, ডেলিগেট প্যাটার্ন এবং closures-এ weak ব্যবহার করুন। Kotlin-এর জন্য, WeakReference বা Lifecycle-aware উপাদান ব্যবহার করুন যা মালিক ধ্বংস হলে স্বয়ংক্রিয়ভাবে রেফারেন্স পরিষ্কার করে। উভয় পদ্ধতিতে, লক্ষ্য একই — শক্তিশালী রেফারেন্সগুলি দূর করা যেখানে তারা একটি অবিচ্ছেদ্য ধারণ শৃঙ্খল তৈরি করে।