আবর্জনা সংগ্রহ করা ভাষাগুলিতে অবজেক্ট ডেস্ট্রাক্টর দৃষ্টান্ত কেন ব্যাপকভাবে অনুপস্থিত?


27

আবর্জনা সংগৃহীত ভাষার নকশা সম্পর্কে সিদ্ধান্তের অন্তর্দৃষ্টি খুঁজছেন। কোনও ভাষা বিশেষজ্ঞ আমাকে আলোকিত করতে পারে? আমি একটি সি ++ পটভূমি থেকে এসেছি, তাই এই অঞ্চলটি আমার কাছে বিস্মিত।

দেখে মনে হচ্ছে রুবি, জাভাস্ক্রিপ্ট / ইএস 6 / ইএস 7, অ্যাকশন স্ক্রিপ্ট, লুয়া ইত্যাদির মতো ওওপি অবজেক্ট সাপোর্ট সহ প্রায় সমস্ত আধুনিক আবর্জনা সংগ্রহ করা ভাষা সম্পূর্ণরূপে ডেস্ট্রাক্টরকে বাদ দেয় / দৃষ্টান্ত চূড়ান্ত করে। পাইথনকে একমাত্র এটির class __del__()পদ্ধতি বলে মনে হয় । কেন? স্বয়ংক্রিয় আবর্জনা সংগ্রহের সাথে ভাষার মধ্যে কি কার্যকরী / তাত্ত্বিক সীমাবদ্ধতা রয়েছে যা কোনও ধ্বংসকারীকে কার্যকরভাবে কার্যকর করা / অবজেক্টগুলিতে চূড়ান্তকরণ পদ্ধতি কার্যকর করে?

আমি এটি অত্যন্ত অভাব বোধ করি যে এই ভাষাগুলি মেমরিকে পরিচালনা করার উপযুক্ত একমাত্র উত্স হিসাবে বিবেচনা করে । সকেট, ফাইল হ্যান্ডলগুলি, অ্যাপ্লিকেশনের রাজ্যগুলির সম্পর্কে কী? অ-মেমোরি রিসোর্সগুলি পরিষ্কার করার জন্য কাস্টম যুক্তি প্রয়োগ করার ক্ষমতা ছাড়াই এবং অবজেক্ট চূড়ান্তকরণের বিষয়ে বলা হয়েছে, আমাকে কাস্টম myObject.destroy()স্টাইল কল দিয়ে আমার অ্যাপ্লিকেশনটি ফাঁকা করতে হবে , ক্লিনআপ যুক্তিকে আমার "ক্লাস" এর বাইরে রেখে, চেষ্টা করা এনক্যাপসুলেশন ভেঙে দেওয়া এবং আমার পুনরায় মুক্তি দেওয়া দরকার জিসি দ্বারা স্বয়ংক্রিয়ভাবে পরিচালিত হওয়ার পরিবর্তে মানব ত্রুটির কারণে রিসোর্সেস ফাঁসের অ্যাপ্লিকেশন।

ল্যাঙ্গুয়েজ ডিজাইনের সিদ্ধান্তগুলি কী কী যা এই ভাষাগুলি অবজেক্ট ডিসপ্লেতে কাস্টম লজিক কার্যকর করার কোনও উপায় না নিয়ে যায়? আমি কল্পনা করতে হবে একটি ভাল কারণ আছে। আমি প্রযুক্তিগত এবং তাত্ত্বিক সিদ্ধান্তগুলি আরও ভালভাবে বুঝতে চাই যার ফলে এই ভাষাগুলি অবজেক্ট ধ্বংস / চূড়ান্তকরণের পক্ষে সমর্থন রাখেনি।

হালনাগাদ:

আমার প্রশ্নের বাক্যাংশটি দেওয়ার আরও ভাল উপায়:

শ্রেণীর বা শ্রেণীর মতো কাঠামোর সাথে কাস্টম ইনস্ট্যান্টেশন (কনস্ট্রাক্টর) পাশাপাশি কোনও ভাষাতে অবজেক্টের দৃষ্টান্তগুলির অন্তর্নিহিত ধারণা থাকবে, তবুও ধ্বংসটি সম্পূর্ণভাবে বাদ দেওয়া / কার্যকারিতা চূড়ান্ত করা হবে কেন? যে ভাষাগুলি স্বয়ংক্রিয় আবর্জনা সংগ্রহের প্রস্তাব দেয় তারা অবজেক্ট ধ্বংস / চূড়ান্তকরণ সমর্থন করার পক্ষে প্রধান প্রার্থী বলে মনে হয় কারণ যখন কোনও বস্তু আর ব্যবহারে থাকবে না তখন তারা 100% নিশ্চিততার সাথে জানে। তবুও সেগুলির বেশিরভাগ ভাষা এটি সমর্থন করে না।

আমি মনে করি না এটি এমন একটি ক্ষেত্রে যেখানে ডেস্ট্রাক্টর কখনই ডাকা না যায়, কারণ এটি একটি মেমরির ফাঁস হবে, যা জিসিএস এড়াতে ডিজাইন করা হয়েছে। আমি একটি সম্ভাব্য যুক্তি দেখতে পেয়েছিলাম যে ডেস্ট্রাক্টর / ফাইনালাইজার ভবিষ্যতে কোনও অনির্দিষ্ট সময় না আসা পর্যন্ত কল করতে পারে না, তবে এটি জাভা বা পাইথনকে কার্যকারিতা সমর্থন করা থেকে বিরত রাখেনি।

অবজেক্ট চূড়ান্তকরণের কোনও ফর্মকে সমর্থন না করার মূল ভাষা নকশার কারণগুলি কী কী?


9
সম্ভবত কারণ finalize/ destroyএকটি মিথ্যা? এটি কার্যকর করা হবে এমন কোন গ্যারান্টি নেই। এবং, এমনকি যদি আপনি জানেন না কখন (স্বয়ংক্রিয় আবর্জনা সংগ্রহের দেওয়া হয়েছে), এবং প্রয়োজনীয় প্রসঙ্গে থাকলেও (এটি ইতিমধ্যে সংগ্রহ করা হতে পারে)। সুতরাং অন্যান্য উপায়ে সামঞ্জস্যপূর্ণ অবস্থা নিশ্চিত করা নিরাপদ এবং কেউ প্রোগ্রামারকে এটি করতে বাধ্য করতে পারে।
রাফেল

1
আমি মনে করি এই প্রশ্নটি সীমান্তের অফটোপিক। আমরা যেভাবে বিনোদন দিতে চাই এটি কী কোনও প্রোগ্রামিং ল্যাঙ্গুয়েজ ডিজাইনের প্রশ্ন, বা প্রোগ্রামিংয়ের দিকে আরও ওরিয়েন্টেড কোনও সাইটের পক্ষে প্রশ্ন? সম্প্রদায় ভোট, দয়া করে।
রাফেল

14
এটি পিএল ডিজাইনে একটি সূক্ষ্ম প্রশ্ন, আসুন এটি করা যাক।
আন্দ্রেজ বাউয়ার

3
এটি সত্যই কোনও স্থির / গতিশীল পার্থক্য নয়। অনেক স্থির ভাষার চূড়ান্তকরণকারী নেই। আসলে, সংখ্যালঘুতে চূড়ান্তকরণকারী ভাষাগুলি কি ভাষা নয়?
আন্দ্রেজ বাউর

1
ভাবেন এখানে কিছু প্রশ্ন আছে ... আপনি শর্তগুলি আরও কিছুটা সংজ্ঞায়িত করলে ভাল হবে be জাভা একটি অবশেষে ব্লক আছে যা অবজেক্ট ধ্বংসের সাথে বাঁধা নয় তবে পদ্ধতি প্রস্থান থেকে বেরিয়ে এসেছে। সংস্থানগুলি মোকাবেলা করার অন্যান্য উপায়ও রয়েছে। উদাহরণস্বরূপ জাভাতে, একটি সংযোগ পুলটি এমন সংযোগগুলির সাথে ডিল করতে পারে যা অব্যবহৃত [x] সময়ের সাথে সাথে পুনরায় দাবী করে im মার্জিত নয় তবে এটি কাজ করে। আপনার প্রশ্নের উত্তরের অংশটি হ'ল আবর্জনা সংগ্রহ মোটামুটি একটি নিরক্ষুবাদী, তাত্ক্ষণিক প্রক্রিয়া নয় এবং বস্তুগুলি আর ব্যবহার না করে চালিত হয় না তবে মেমরির সীমাবদ্ধতা / সিলিংগুলি চালিত করে।
vzn

উত্তর:


10

আপনি যে প্যাটার্নটির কথা বলছেন, যেখানে বস্তুগুলি কীভাবে তাদের সংস্থানগুলি পরিষ্কার করতে জানে, তিনটি প্রাসঙ্গিক বিভাগে পড়ে। আসুন আমরা চূড়ান্তকারীগুলির সাথে ধ্বংসকারীদের সংঘাত না করি - কেবলমাত্র একটি আবর্জনা সংগ্রহের সাথে সম্পর্কিত:

  • Finalizer প্যাটার্ন : পরিষ্করণ পদ্ধতি স্বয়ংক্রিয়ভাবে ঘোষণা প্রোগ্রামার দ্বারা সংজ্ঞায়িত, স্বয়ংক্রিয়ভাবে বলা হয়।

    চূড়ান্তকারীদের কোনও আবর্জনা সংগ্রহকারী কর্তৃক অবরুদ্ধ হওয়ার আগে স্বয়ংক্রিয়ভাবে কল করা হয়। পদটি প্রয়োগ হয় যদি নিযুক্ত আবর্জনা সংগ্রহের অ্যালগরিদম বস্তুর জীবনচক্র নির্ধারণ করতে পারে।

  • বিনাশকারী প্যাটার্ন : পরিষ্করণ পদ্ধতি স্বয়ংক্রিয়ভাবে ঘোষণা প্রোগ্রামার দ্বারা সংজ্ঞায়িত, স্বয়ংক্রিয়ভাবে কেবল কখনও কখনও বলা হয়।

    স্ট্যাক-বরাদ্দকৃত বস্তুগুলির জন্য ডেস্ট্রাক্টরগুলিকে স্বয়ংক্রিয়ভাবে ডাকা যেতে পারে (কারণ বস্তুর আজীবন হতাশাগ্রস্থ হয়) তবে গাদা-বরাদ্দকৃত বস্তুর জন্য সমস্ত সম্ভাব্য সম্পাদনের পথে অবশ্যই স্পষ্টভাবে ডেকে আনতে হবে (কারণ অবজেক্টের আজীবন ননডেটেরিমেন্টিক)।

  • কার্যনির্বাহী প্যাটার্ন : পরিষ্করণ পদ্ধতি ঘোষণা সংজ্ঞায়িত এবং প্রোগ্রামারের বলা হয়।

    প্রোগ্রামাররা একটি নিষ্পত্তি পদ্ধতি তৈরি করে এবং এগুলি নিজেরাই কল করে - এটিই আপনার কাস্টম myObject.destroy()পদ্ধতিটি পড়ে। যদি নিষ্পত্তি সম্পূর্ণরূপে প্রয়োজন হয়, তবে নিষ্পত্তিকারীদের অবশ্যই সমস্ত সম্ভাব্য কার্যকর পথে চিহ্নিত করা উচিত।

ফাইনালাইজারগুলি হ'ল ড্রেডস যা আপনি খুঁজছেন।

চূড়ান্তকরণের প্যাটার্ন (যে প্রশ্নটি আপনার প্রশ্নটি জিজ্ঞাসা করছে) হ'ল আবর্জনা সংগ্রহকারী দ্বারা পারস্পরিক পুনঃনির্ধারণের জন্য সিস্টেম রিসোর্সের (সকেট, ফাইল বর্ণনাকারী, ইত্যাদি) সাথে অবজেক্টগুলিকে যুক্ত করার প্রক্রিয়া। তবে, চূড়ান্তকরণগুলি মূলত ব্যবহৃত আবর্জনা সংগ্রহের অ্যালগরিদমের করুণায়।

আপনার এই অনুমান বিবেচনা করুন:

যে ভাষাগুলি স্বয়ংক্রিয় আবর্জনা সংগ্রহের অফার করে ... কোনও বস্তু আর ব্যবহারে না থাকলে 100% নিশ্চিততার সাথে জানুন।

প্রযুক্তিগতভাবে মিথ্যা (আপনাকে ধন্যবাদ, বাবু)। আবর্জনা সংগ্রহ মৌলিকভাবে মেমরি সম্পর্কে, বস্তুর নয় objects যদি বা যখন কোনও সংগ্রহ অ্যালগরিদম বুঝতে পারে যে কোনও জিনিসের স্মৃতি আর ব্যবহারে না থাকে তবে এটি নির্ভর করে অ্যালগরিদম এবং (সম্ভবত) কীভাবে আপনার অবজেক্টগুলি একে অপরকে রেফার করে। চলুন দুই ধরণের রানটাইম আবর্জনা সংগ্রহকারীদের সম্পর্কে কথা বলি। এগুলি মৌলিক কৌশলগুলিতে পরিবর্তন ও বৃদ্ধির প্রচুর উপায় রয়েছে:

  1. ট্র্যাকিং জিসি। এই ট্রেস মেমরি, বস্তু নয়। এটি না করা পর্যন্ত তারা মেমরি থেকে পাওয়া বস্তুর পিছনে উল্লেখগুলি বজায় রাখে না। সংযোজন না করা অবধি, এই জিসিগুলি কখনই কোনও অবজেক্ট চূড়ান্ত করা যায় তা জানবে না, এমনকি যদি এটির স্মৃতি অ্যাক্সেসযোগ্য হয় না তখনও তারা জানে। অতএব, চূড়ান্তকরণের কলগুলি গ্যারান্টিযুক্ত নয়।

  2. রেফারেন্স গণনা জিসি । এগুলি মেমরি ট্র্যাক করতে অবজেক্ট ব্যবহার করে। তারা রেফারেন্সের নির্দেশিত গ্রাফের সাথে পুনরায় আপত্তিজনকতার মডেল। যদি আপনার অবজেক্ট রেফারেন্স গ্রাফটিতে একটি চক্র থাকে, তবে চক্রের সমস্ত বস্তুর কাছে তাদের চূড়ান্তকরণকারী কখনও কল করা হবে না (প্রোগ্রাম সমাপ্তি হওয়া পর্যন্ত, স্পষ্টতই)। আবার, চূড়ান্তকরণের কলগুলি গ্যারান্টিযুক্ত নয়।

TLDR

আবর্জনা সংগ্রহ করা কঠিন এবং বৈচিত্র্যময়। প্রোগ্রাম সমাপ্তির আগে একটি চূড়ান্তকরণের কলটির গ্যারান্টি দেওয়া যায় না।


আপনি সঠিক যে এটি স্থির বনাম গতিশীল নয়। আবর্জনা সংগ্রহ করা ভাষা নিয়ে এটি একটি সমস্যা। আবর্জনা সংগ্রহ একটি জটিল সমস্যা এবং সম্ভবত এটি প্রাথমিক কারণ হিসাবে বিবেচনার জন্য অনেক প্রান্তের কেস রয়েছে (যেমন লজিকের finalize()কারণে যদি বিষয়টিকে পরিষ্কার করে দেওয়া হয় তবে আবার কী ঘটে ?)। যাইহোক, প্রোগ্রাম সমাপ্তির আগে চূড়ান্তকরণকারীর ডাক দেওয়ার গ্যারান্টি দিতে অক্ষম হওয়ায় জাভা এটি সমর্থন করা থেকে বিরত রাখেনি। আপনার উত্তরটি ভুল না বলা, কেবল অসম্পূর্ণ। এখনও একটি খুব ভাল পোস্ট। ধন্যবাদ.
dbcb

সাহায্য করার জন্য ধন্যবাদ. আমার উত্তরটি সম্পূর্ণ করার এখানে একটি প্রচেষ্টা: স্পষ্টভাবে চূড়ান্তকরণকারীকে বাদ দিয়ে, একটি ভাষা তার ব্যবহারকারীদের তাদের নিজস্ব সংস্থানগুলি পরিচালনা করতে বাধ্য করে। অনেক ধরণের সমস্যার জন্য এটি সম্ভবত একটি অসুবিধা। ব্যক্তিগতভাবে, আমি জাভা পছন্দের পছন্দ করেন, কারণ আমি finalizers শক্তি আছে এবং আমার লেখা এবং আমার নিজের কার্যনির্বাহী ব্যবহার থেকে বাঁধন কিছুই নেই। জাভা বলছে, "আরে, প্রোগ্রামার। আপনি বোকা নন, তাই এখানে ফাইনালাইজার দেওয়া হয়েছে। একটু সাবধানতা অবলম্বন করুন।"
kdbanman

1
এটি আবর্জনা সংগ্রহ করা ভাষাগুলির সাথে সম্পর্কিত তা বোঝাতে আমার মূল প্রশ্নটি আপডেট করেছে। আপনার উত্তর গ্রহণ করা। উত্তর দেওয়ার জন্য সময় দেওয়ার জন্য ধন্যবাদ।
dbcb

সাহায্য করতে পারে খুশি. আমার মন্তব্য স্পষ্টকরণ কি আমার উত্তর পরিষ্কার করেছে?
kdbanman

2
এটা ভালো. আমার কাছে, এখানে আসল উত্তরটি হ'ল ভাষাগুলি এটি প্রয়োগ না করা বেছে নেয় কারণ অনুভূত মান কার্যকারিতা বাস্তবায়নের সমস্যাগুলিকে ছাড়িয়ে যায় না। এটি অসম্ভব নয় (যেমন জাভা এবং পাইথন দেখায়), তবে এমন একটি বাণিজ্য রয়েছে যা বহু ভাষা না করা বেছে নেয়।
dbcb

5

সংক্ষেপে

চূড়ান্তকরণ কোনও আবর্জনা সংগ্রহকারীদের দ্বারা পরিচালিত হওয়া সাধারণ বিষয় নয়। রেফারেন্স গণনা জিসির সাথে এটি ব্যবহার করা সহজ, তবে জিসির এই পরিবারটি প্রায়শই অসম্পূর্ণ থাকে যার ফলে কিছু বস্তু এবং কাঠামোর ধ্বংস এবং চূড়ান্তকরণের স্পষ্ট ট্রিগার দ্বারা মেমরি ফাঁসের ক্ষতিপূরণ করা প্রয়োজন। আবর্জনা সংগ্রহকারীদের সন্ধান করা আরও কার্যকর, তবে কেবল অব্যবহৃত স্মৃতি চিহ্নিতকরণের বিপরীতে চূড়ান্ত ও ধ্বংস হওয়া অবজেক্টটি সনাক্ত করা অনেক বেশি শক্ত করে তোলে, এইভাবে সময় ও স্থান ব্যয় সহ আরও জটিল পরিচালনা প্রয়োজন of রুপায়ণ.

ভূমিকা

আমি ধরে নিয়েছি যে আপনি যা জিজ্ঞাসা করছেন তা হ'ল আবর্জনা সংগ্রহ করা ভাষাগুলি কেন আবর্জনা সংগ্রহের প্রক্রিয়াটির মধ্যে স্বয়ংক্রিয়ভাবে ধ্বংস / চূড়ান্তকরণ পরিচালনা করে না, মন্তব্য দ্বারা নির্দেশিত হিসাবে:

আমি এটি অত্যন্ত অভাব বোধ করি যে এই ভাষাগুলি মেমরিকে পরিচালনা করার উপযুক্ত একমাত্র উত্স হিসাবে বিবেচনা করে। সকেট, ফাইল হ্যান্ডলগুলি, অ্যাপ্লিকেশনের রাজ্যগুলির সম্পর্কে কী?

আমি kdbanman প্রদত্ত গৃহীত উত্তরের সাথে একমত নই । যদিও সেখানে বর্ণিত তথ্যগুলি বেশিরভাগই সঠিক, যদিও রেফারেন্স গণনার পক্ষে দৃ strongly় পক্ষপাতদুষ্ট, আমি বিশ্বাস করি না যে তারা প্রশ্নের মধ্যে অভিযোগ করা পরিস্থিতি সঠিকভাবে ব্যাখ্যা করেছে।

আমি বিশ্বাস করি না যে উত্তরটিতে যে পরিভাষাটি বিকশিত হয়েছে তা একটি ইস্যুতে অনেক বেশি, এবং বিষয়গুলিকে বিভ্রান্ত করার সম্ভাবনা বেশি। প্রকৃতপক্ষে, যেমন উপস্থাপন করা হয়েছে, পরিভাষাগুলি বেশিরভাগ ক্ষেত্রে কীভাবে করা হয় তার চেয়ে পদ্ধতিগুলি সক্রিয় করার পদ্ধতি দ্বারা নির্ধারিত হয়। মুল বক্তব্যটি হ'ল সমস্ত ক্ষেত্রে, কোনও ক্লিনআপ প্রক্রিয়া ব্যবহার করে আর কোনও জিনিস চূড়ান্ত করার প্রয়োজন নেই এবং এটি যে যা সংস্থান ব্যবহার করে চলেছে তা মুক্ত করার জন্য, স্মৃতি কেবল তাদের মধ্যে একটি। আদর্শভাবে, যখন আবর্জনা আর ব্যবহার করা যায় না তখন সমস্ত কিছুই স্বয়ংক্রিয়ভাবে করা উচিত, কোনও আবর্জনা সংগ্রাহকের মাধ্যমে। অনুশীলনে, জিসি নিখোঁজ হতে পারে বা তার ঘাটতি থাকতে পারে এবং চূড়ান্তকরণ এবং পুনঃসংশ্লিষ্টকরণের প্রোগ্রামটি দ্বারা স্পষ্ট ট্রিগার দ্বারা এটির ক্ষতিপূরণ দেওয়া হয়।

প্রোগ্রামটির দ্বারা স্পষ্ট ট্রিগারিং একটি সমস্যা হ'ল এটি যখন প্রোগ্রামিং ত্রুটিগুলি বিশ্লেষণের পক্ষে কঠোরভাবে মঞ্জুরি দেয় তখন যখন ব্যবহারে থাকা কোনও বস্তুটি স্পষ্টভাবে বন্ধ হয়ে যায়।

সুতরাং রিসোর্সগুলি দাবি করতে স্বয়ংক্রিয় আবর্জনা সংগ্রহের উপর নির্ভর করা আরও ভাল। তবে দুটি বিষয় রয়েছে:

  • কিছু আবর্জনা সংগ্রহের কৌশল মেমরির ফুটোকে অনুমতি দেয় যা সম্পদের পুরো পুনরুদ্ধার প্রতিরোধ করে। এটি রেফারেন্স গণনা জিসির জন্য সুপরিচিত, তবে যত্ন ছাড়াই কিছু ডেটা সংগঠন ব্যবহার করার সময় অন্যান্য জিসি কৌশলগুলির জন্য উপস্থিত হতে পারে (পয়েন্টটি এখানে আলোচনা করা হয়নি)।

  • জিসি কৌশলটি মেমোরি সংস্থানগুলি আর ব্যবহার না করে সনাক্তকরণে ভাল হতে পারে, তবে এতে থাকা বিষয়গুলি চূড়ান্ত করা সহজ নাও হতে পারে এবং যা এই বিষয়গুলি দ্বারা ব্যবহৃত অন্যান্য সংস্থানগুলি পুনরায় দাবি করার সমস্যাটিকে জটিল করে তোলে, যা প্রায়শই চূড়ান্তকরণের উদ্দেশ্য।

পরিশেষে, একটি গুরুত্বপূর্ণ বিষয় যা প্রায়শই ভুলে যায় তা হ'ল জিসি চক্রগুলি কোনও কিছুর দ্বারাই ট্রিগার হতে পারে, কেবল স্মৃতির ঘাটতি নয়, যদি সঠিক হুক সরবরাহ করা হয় এবং যদি কোনও জিসি চক্রের ব্যয়টিকে মূল্য হিসাবে বিবেচনা করা হয়। সুতরাং কোনও প্রকার মুক্ত করার আশায় যখন কোনও ধরণের সংস্থান অনুপস্থিত থাকে তখন কোনও জিসি শুরু করা পুরোপুরি ঠিক।

আবর্জনা সংগ্রহকারীদের গণনা রেফারেন্স

রেফারেন্স গণনা দুর্বল আবর্জনা সংগ্রহের কৌশল , যা চক্রগুলি সঠিকভাবে পরিচালনা করবে না। অপ্রচলিত কাঠামো ধ্বংস করতে এবং স্মৃতি পুনরুদ্ধার করার ক্ষেত্রে এটি দুর্বল হওয়ায় অন্য সংস্থানগুলি পুনরায় দাবি করার জন্য এটি সত্যই দুর্বল হবে। তবে ফাইনালাইজারগুলি রেফারেন্স গণনা আবর্জনা সংগ্রহকারী (জিসি) দিয়ে খুব সহজেই ব্যবহার করা যেতে পারে, যেহেতু একটি রেফ-কাউন্ট জিসি কোনও কাঠামো পুনরায় দাবি করে যখন তার রেফ গণনাটি 0 এ নেমে যায়, সেই সময়ে তার ঠিকানাটি তার ধরণের সাথে একসাথে জানা থাকে, হয় স্থিতিশীলভাবে বা গতিশীল। সুতরাং যথাযথ চূড়ান্তকরণকারী প্রয়োগের পরে এবং সঠিকভাবে চূড়ান্তভাবে সমস্ত দৃষ্টিকোণ বস্তুগুলিতে কল করা (সম্ভবত চূড়ান্তকরণ পদ্ধতির মাধ্যমে) মেমরিটিকে পুনরায় দাবি করা সম্ভব।

সংক্ষেপে বলা যায়, রেফ কাউন্টিং জিসির মাধ্যমে চূড়ান্তকরণ কার্যকর করা সহজ, তবে স্মৃতি পুনরুদ্ধারের যে মাত্রা ভুগছে ঠিক তেমনই সেই জিসির "অসম্পূর্ণতা" দ্বারা ভোগেন। অন্য কথায়, রেফারেন্স গণনা সহ, স্মৃতি হ'ল সকেট, ফাইল হ্যান্ডেল ইত্যাদির মতো অন্যান্য সংস্থাগুলির মতো খারাপভাবে পরিচালিত হয়

প্রকৃতপক্ষে, রেফ কাউন্ট জিসি লুপিং স্ট্রাকচারগুলি (সাধারণভাবে) পুনরায় দাবি করতে অক্ষমতা মেমরি ফাঁস হিসাবে দেখা যেতে পারে । আপনি সমস্ত জিসি মেমরি ফুটো এড়ানোর আশা করতে পারবেন না। এটি জিসি অ্যালগরিদমের উপর নির্ভর করে, এবং টাইপ স্ট্রাকচারের তথ্যগুলিতে গতিশীলভাবে উপলব্ধ (উদাহরণস্বরূপ রক্ষণশীল জিসি )।

আবর্জনা সংগ্রহকারীদের সন্ধান করা

এই জাতীয় ফুটো ছাড়াই জিসির আরও শক্তিশালী পরিবার হ'ল ট্রেসিং পরিবার যা মেমোরিটির লাইভ অংশগুলি সন্ধান করে যা ভালভাবে চিহ্নিত রুট পয়েন্টার থেকে শুরু করে। এই ট্রেসিং প্রক্রিয়ায় মেমরির সমস্ত অংশ যা পরিদর্শন করা হয় না (যা আসলে বিভিন্ন উপায়ে পচে যেতে পারে তবে আমাকে সহজ করতে হবে) মেমরির অব্যবহৃত অংশ যা এভাবে পুনরায় দাবি করা যেতে পারে 1 । এই সংগ্রাহকরা সমস্ত মেমরি অংশ পুনরায় দাবি জানাতে পারবেন যা প্রোগ্রামের দ্বারা আর অ্যাক্সেস করা যায় না, তা সে যাই হোক না কেন। এটি বিজ্ঞপ্তি কাঠামোর পুনরায় দাবি আদায় করে এবং আরও উন্নত জিসি এই দৃষ্টান্তের কিছু পরিবর্তনের উপর ভিত্তি করে তৈরি হয়, কখনও কখনও অত্যন্ত পরিশীলিত। এটি কয়েকটি ক্ষেত্রে রেফারেন্স গণনার সাথে মিলিত হতে পারে এবং এর দুর্বলতাগুলি পূরণ করে।

একটি সমস্যা হ'ল আপনার বিবৃতি (প্রশ্নের শেষে):

যে ভাষাগুলি স্বয়ংক্রিয় আবর্জনা সংগ্রহের প্রস্তাব দেয় তারা অবজেক্ট ধ্বংস / চূড়ান্তকরণ সমর্থন করার পক্ষে প্রধান প্রার্থী বলে মনে হয় কারণ যখন কোনও বস্তু আর ব্যবহারে থাকবে না তখন তারা 100% নিশ্চিততার সাথে জানে।

সংগ্রহকারীদের সন্ধানের জন্য প্রযুক্তিগতভাবে ভুল

১০০% নিশ্চিততার সাথে যা জানা যায় তা হ'ল মেমরির অংশগুলি আর ব্যবহারে নেই । (আরও স্পষ্টভাবে, এটি বলা উচিত যে এগুলি আর অ্যাক্সেসযোগ্য নয় , কারণ প্রোগ্রামের যুক্তি অনুসারে কিছু অংশ যা আর ব্যবহার করা যায় না, যদি প্রোগ্রামে তাদের কাছে এখনও অব্যর্থ পয়েন্টার থাকে তবে এখনও ব্যবহার হিসাবে বিবেচিত হয়) ডেটা।) তবে মেমরির এখন অব্যবহৃত অংশগুলিতে কোন অব্যবহৃত বস্তুগুলি সংরক্ষণ করা হতে পারে তা জানতে আরও প্রক্রিয়াজাতকরণ এবং উপযুক্ত কাঠামোগুলি প্রয়োজন । প্রোগ্রামটির পরিচিতি থেকে এটি নির্ধারণ করা যায় না, যেহেতু প্রোগ্রামটি আর মেমরির এই অংশগুলির সাথে সংযুক্ত থাকে না।

এইভাবে আবর্জনা সংগ্রহের পরে, আপনার কাছে মেমরির টুকরো রয়েছে যাতে অবজেক্টগুলি রয়েছে যা আর ব্যবহারযোগ্য নয়, তবে সঠিক চূড়ান্তকরণ প্রয়োগ করার জন্য এই বিষয়গুলি কী তা জানার কোনও অগ্রাধিকার নেই। তদ্ব্যতীত, ট্রেসিং সংগ্রাহক যদি মার্ক-ও-সুইপ প্রকারের হয় তবে এটি হতে পারে যে কিছু টুকরো টুকরো টুকরো থাকতে পারে যা ইতিমধ্যে পূর্ববর্তী জিসি পাসে চূড়ান্ত হয়ে গেছে, তবে খণ্ড খণ্ড কারণে এটি ব্যবহৃত হয়নি। তবে এটি প্রসারিত সুস্পষ্ট টাইপিং ব্যবহার করে ডিল করা যেতে পারে।

সরল সংগ্রাহক কেবল মেমোরির এই টুকরোগুলিকে পুনরায় দাবি করতে পারবেন, এমন কোনও পদক্ষেপ ছাড়াই, চূড়ান্তকরণের জন্য সেই অব্যবহৃত মেমরিটি অন্বেষণ করতে, সেখানে থাকা অবজেক্টগুলি চিহ্নিত করতে এবং চূড়ান্তকরণ পদ্ধতি প্রয়োগ করতে একটি নির্দিষ্ট পাসের প্রয়োজন হয়। তবে এই ধরনের অন্বেষণের জন্য সেখানে সংরক্ষণ করা ধরণের পদার্থগুলির নির্ধারণের প্রয়োজন হয় এবং যথাযথ চূড়ান্তকরণ প্রয়োগের জন্য প্রকারের সংকল্পও প্রয়োজন হয়, যদি থাকে তবে।

সুতরাং এটি বিভিন্ন প্রযুক্তির মাধ্যমে সেই পাসের সময় যথাযথ ধরণের তথ্য উপলভ্য করতে জিসি সময় (অতিরিক্ত পাস) এবং সম্ভবত অতিরিক্ত মেমরির ব্যয়কে অতিরিক্ত খরচ বোঝায়। এই ব্যয়গুলি তাত্পর্যপূর্ণ হতে পারে কারণ কেউ প্রায়শই কয়েকটি কয়েকটি বিষয় চূড়ান্ত করতে চায়, যখন সময় এবং স্পেসের ওভারহেড সমস্ত বস্তুকে উদ্বেগ করতে পারে।

আরেকটি বিষয় হ'ল সময় এবং স্পেসের ওভারহেড কেবলমাত্র জিসি এক্সিকিউশন নয়, প্রোগ্রাম কোড প্রয়োগের বিষয়ে উদ্বেগ প্রকাশ করতে পারে।

নির্দিষ্ট সমস্যাগুলিতে ইঙ্গিত করে আমি আরও সঠিক উত্তর দিতে পারি না, কারণ আপনার তালিকৃত অনেক ভাষার স্পেসিফিকেশন আমি জানি না। সি এর ক্ষেত্রে, টাইপিং একটি খুব কঠিন সমস্যা যা রক্ষণশীল সংগ্রাহকদের বিকাশের দিকে নিয়ে যায়। আমার ধারণাটি এটি সি ++ কেও প্রভাবিত করে তবে আমি সি ++ তে কোনও বিশেষজ্ঞ নই। এটি কনফারভেটিভ জিসি নিয়ে গবেষণা বেশিরভাগ গবেষক হ্যান্স বোহম দ্বারা নিশ্চিত করা হয়েছে বলে মনে হয় । কনজারভেটিভ জিসি পদ্ধতিতে সমস্ত অব্যবহৃত মেমোরিটি সঠিকভাবে পুনরায় দাবি করতে পারবেন না কারণ এতে ডেটাতে সুনির্দিষ্ট ধরণের তথ্যের অভাব থাকতে পারে। একই কারণে, এটি পদ্ধতিগতভাবে চূড়ান্তকরণ পদ্ধতিগুলি প্রয়োগ করতে সক্ষম হবে না।

সুতরাং, আপনি কিছু ভাষা থেকে যেমন জানেন, আপনি যা জিজ্ঞাসা করছেন তা করা সম্ভব। তবে তা নিখরচায় আসে না। ভাষা এবং এর প্রয়োগের উপর নির্ভর করে আপনি যখন বৈশিষ্ট্যটি ব্যবহার না করেন তখনও এটিতে ব্যয় হতে পারে। এই সমস্যাগুলি সমাধান করার জন্য বিভিন্ন কৌশল এবং বাণিজ্য-অফগুলি বিবেচনা করা যেতে পারে, তবে এটি যুক্তিযুক্ত আকারের উত্তরের বাইরে beyond

1 - এটি ট্রেসিং সংগ্রহের একটি বিমূর্ত উপস্থাপনা (উভয় অনুলিপি এবং চিহ্ন-এবং-স্যুইপ জিসি সমন্বিত), ট্রেসিং সংগ্রাহকের ধরণ অনুসারে জিনিসগুলি পৃথক হয় এবং মেমরির অব্যবহৃত অংশ অন্বেষণ করা আলাদা হয়, অনুলিপি বা চিহ্ন এবং উপর নির্ভর করে সুইপ ব্যবহার করা হয়।


আপনি আবর্জনা সংগ্রহের উপর প্রচুর দুর্দান্ত বিবরণ দেন। তবে আপনার উত্তরটি আসলে আমার সাথে একমত নয় - আপনার বিমূর্ততা এবং আমার টিএলডিআর মূলত একই জিনিসটি বলছে। এবং এটির মূল্য কী, তার জন্য আমার উত্তর উল্লেখযোগ্য জিসি কে উদাহরণস্বরূপ ব্যবহার করে, "শক্তিশালী পক্ষপাত" নয়।
kdbanman

আরও পুঙ্খানুপুঙ্খভাবে পড়ার পরে আমি দ্বিমত দেখছি। আমি সেই অনুযায়ী সম্পাদনা করব। এছাড়াও, আমার পরিভাষাটি দ্ব্যর্থহীন ছিল। প্রশ্নটি ছিল চূড়ান্তকারী এবং ধ্বংসকারীদের বিমোহিত করা, এমনকি একই শ্বাসে নিষ্পত্তিকারীদেরও উল্লেখ করেছিল। সঠিক শব্দগুলি ছড়িয়ে দেওয়া এটি সার্থক।
kdbanman

@kdbanman অসুবিধা হচ্ছিল যে আমি আপনাকে উভয়কেই সম্বোধন করছিলাম, কারণ আপনার উত্তরটি উল্লেখ হিসাবে দাঁড়িয়ে ছিল। উদাহরণস্বরূপ উদাহরণ হিসাবে আপনি রেফ কাউন্ট ব্যবহার করতে পারবেন না কারণ এটি একটি দুর্বল জিসি, খুব কমই ভাষাতে ব্যবহৃত হয় (ওপি দ্বারা উদ্ধৃত ভাষাগুলি পরীক্ষা করুন), যার জন্য চূড়ান্তর সংযোজন করা আসলে সহজ হবে (তবে সীমিত ব্যবহারের সাথে)। ট্র্যাকিং সংগ্রহকারীরা প্রায় সর্বদা ব্যবহৃত হয়। তবে চূড়ান্তকরণকারীগুলি এগুলিকে আঁকানো শক্ত, কারণ মৃত বস্তুগুলি জানা যায় না (যে বক্তব্যটি আপনি সঠিক বলে মনে করছেন তার বিপরীতে)। স্ট্যাটিক এবং গতিশীল টাইপিংয়ের মধ্যে পার্থক্য অপ্রাসঙ্গিক, ডেটা স্টোরের গতিশীল টাইপিং দ্বারা প্রয়োজনীয়।
বাবু

@ কেডব্যানম্যান পরিভাষা সম্পর্কিত, এটি সাধারণভাবে কার্যকর, কারণ এটি বিভিন্ন পরিস্থিতিতে। তবে এখানে এটি কোনও উপকারে আসেনি, যেহেতু প্রশ্নটি জিসিকে চূড়ান্তকরণ স্থানান্তর করার বিষয়ে। বেসিক জিসি কেবল ধ্বংসটি করার কথা। যা প্রয়োজন তা হ'ল পার্থক্য সম্পর্কিত getting memory recycledযা আমি কল করি reclamationএবং এর আগে কিছু ক্লিন-আপ করা যেমন অন্য সংস্থানগুলি দাবি করা বা কিছু বস্তুর টেবিল আপডেট করা, যা আমি কল করি finalization। এগুলি আমার কাছে প্রাসঙ্গিক বিষয় মনে হয়েছিল তবে আমি আপনার পরিভাষার একটি পয়েন্ট মিস করতে পারি যা আমার কাছে নতুন ছিল।
বাবু

1
ধন্যবাদ @ কেডব্যানম্যান, বাবু। ভাল আলোচনা। আমি মনে করি আপনার পোস্ট উভয় একই পয়েন্ট কভার। আপনি উভয়ই ইঙ্গিত হিসাবে, মূল ইস্যুটি ভাষার রানটাইমগুলিতে নিযুক্ত আবর্জনা সংগ্রাহকের বিভাগ হিসাবে উপস্থিত বলে মনে হচ্ছে। আমি এই নিবন্ধটি পেয়েছি , যা আমার জন্য কিছু ভুল ধারণা পরিষ্কার করে। দেখে মনে হচ্ছে আরও শক্তিশালী জিসিএস কেবল নিম্ন স্তরের কাঁচা মেমরি পরিচালনা করে, যা উচ্চ স্তরের অবজেক্টের ধরণগুলিকে জিসিকে অস্বচ্ছভাবে সরবরাহ করে। মেমরি ইন্টার্নাল সম্পর্কে জ্ঞান ছাড়াই, গিসি অবজেক্টগুলি ধ্বংস করতে পারে না। যা আপনার উপসংহার বলে মনে হচ্ছে।
dbcb

4

সিস্টেম প্রোগ্রামিংয়ে ত্রুটি পরিচালনা করার জন্য অবজেক্ট ডেস্ট্রাক্টর প্যাটার্নটি মৌলিক, তবে আবর্জনা সংগ্রহের সাথে কিছুই করার নেই। পরিবর্তে, এটি একটি স্কোপের সাথে অবজেক্টের আজীবন ম্যাচিংয়ের সাথে সম্পর্কযুক্ত এবং প্রথম শ্রেণির ফাংশনগুলির যে কোনও ভাষায় প্রয়োগ / ব্যবহার করা যেতে পারে।

উদাহরণ (সিউডোকোড)। ধরুন আপনার পসিক্স ফাইল বর্ণনাকারী টাইপের মতো একটি "কাঁচা ফাইল" টাইপ রয়েছে। চার মৌলিক অপারেশন আছে, open(), close(), read(), write()। আপনি একটি "নিরাপদ" ফাইল টাইপ প্রয়োগ করতে চান যা সর্বদা নিজের পরে পরিষ্কার হয়ে যায়। (অর্থাৎ এটিতে একটি স্বয়ংক্রিয় নির্মাতা এবং ধ্বংসকারী রয়েছে))

আমি আমাদের ভাষা সঙ্গে ব্যতিক্রম হ্যান্ডলিং হয়েছে অনুমান করব throw, tryএবং finally(ব্যতিক্রম আপনি একটি শৃঙ্খলা যেখানে আপনার টাইপ ব্যবহারকারী একটি বিশেষ মান একটি ত্রুটি নির্দেশ করে সেট আপ করতে পারেন হ্যান্ডলিং ছাড়া ভাষায়।)

আপনি একটি ফাংশন সেট আপ করেছেন যা কোনও ফাংশন গ্রহণ করে যা কাজ করে। কর্মী ফাংশন একটি যুক্তি গ্রহণ করে ("নিরাপদ" ফাইলের একটি হ্যান্ডেল)।

with_file_opened_for_read (string:   filename,
                           function: worker_function(safe_file f)):
  raw_file rf = open(filename, O_RDONLY)
  if rf == error:
    throw File_Open_Error

  try:
    worker_function(rf)
  finally:
    close(rf)

এছাড়াও আপনি এর বাস্তবায়নের প্রদান read()এবং write()জন্য safe_file(যে শুধু কল raw_file read()এবং write())। এখন ব্যবহারকারী ব্যবহার করেsafe_file ধরণের :

...
with_file_opened_for_read ("myfile.txt",
                           anonymous_function(safe_file f):
                             mytext = read(f)
                             ... (including perhaps throwing an error)
                          )

একটি সি ++ ডেস্ট্রাক্টর আসলে একটি try-finallyব্লকের জন্য কেবল সিনট্যাকটিক চিনি । খুব সুন্দর আমি এখানে যা করেছি তা হ'ল safe_fileকনস্ট্রাক্টর এবং ডেস্ট্রাক্টর সহ সি ++ ক্লাসটি কি সংকলন করবে তা রূপান্তর করা। মনে রাখবেন যে সি ++ নেইfinally এর ব্যতিক্রমগুলি নেই, বিশেষত কারণ স্ট্রস্ট্রপ মনে করেছিলেন যে স্পষ্টত ডিসস্ট্রাক্টর ব্যবহার করা সিনট্যাক্টিকভাবে আরও ভাল ছিল (এবং ভাষাটি বেনামে ফাংশন করার আগে তিনি ভাষায় এটি প্রবর্তন করেছিলেন)।

(বহু বছর ধরে লিস্প-এর মতো ভাষাগুলিতে লোকেরা যেভাবে ত্রুটি পরিচালনা করে আসছে তার একটি সরলকরণ এটি 1980 আমি মনে করি ১৯৮০-এর দশকের শেষের দিকে বা 1990-এর দশকের প্রথম দিকে আমি প্রথম এটিতে প্রবেশ করেছি, তবে আমার মনে নেই) where


এটি সি ++ তে স্ট্যাক ভিত্তিক ডেস্ট্রাক্টর প্যাটার্নটির অভ্যন্তরীণ বর্ণনা করে, তবে কেন কোনও আবর্জনা সংগ্রহ করা ভাষা এই জাতীয় কার্যকারিতা কার্যকর করবে না তা ব্যাখ্যা করে না। আপনারা ঠিক থাকতে পারেন যে আবর্জনা সংগ্রহের সাথে এর কোনও যোগসূত্র নেই, তবে এটি সাধারণ বস্তু ধ্বংস / চূড়ান্তকরণের সাথে সম্পর্কিত, যা আবর্জনা সংগ্রহ করা ভাষাগুলিতে কঠিন বা অকার্যকর বলে মনে হয়। সুতরাং সাধারণ ধ্বংস যদি সমর্থিত না হয় তবে স্ট্যাক ভিত্তিক ধ্বংসটিকেও বাদ দেওয়া হবে বলে মনে হচ্ছে।
dbcb

যেমনটি আমি প্রথমদিকে বলেছিলাম: যে কোনও আবর্জনা সংগ্রহ করা ভাষা যা প্রথম শ্রেণির ফাংশনগুলি (বা প্রথম শ্রেণির ফাংশনগুলির কিছুটা আনুমানিক) আপনাকে "বুলেট প্রুফ" ইন্টারফেসগুলি সরবরাহ করার ক্ষমতা দেয় safe_fileএবং with_file_opened_for_read(এমন একটি বস্তু যা যখন সুযোগের বাইরে চলে যায় তখন নিজেকে বন্ধ করে দেয়) )। এটি গুরুত্বপূর্ণ বিষয়, এটির কনস্ট্রাক্টরগুলির মতো একই সিনট্যাক্সটি অপ্রাসঙ্গিক নয়। লিস্প, স্কিম, জাভা, স্কেলা, গো, হাস্কেল, মরিচা, জাভাস্ক্রিপ্ট, ক্লোজার সমস্তই প্রথম শ্রেণির ফাংশনগুলিকে সমর্থন করে, সুতরাং তাদের একই কার্যকর বৈশিষ্ট্য সরবরাহ করার জন্য ডেস্ট্রাক্টরের দরকার নেই।
২৩

আমি মনে করি আপনি যা বলছেন তা আমি দেখছি। যেহেতু ভাষাগুলি ম্যানুয়ালি ডেস্ট্রাক্টরের মতো কার্যকারিতা বাস্তবায়নের জন্য বেসিক বিল্ডিং ব্লকগুলি (চেষ্টা / ধরা / শেষ অবধি, প্রথম শ্রেণির ফাংশন ইত্যাদি) সরবরাহ করে, তাদের জন্য ডেস্ট্রাক্টরের দরকার নেই? আমি দেখতে পেলাম যে কয়েকটি ভাষা সরলতার কারণে সেই পথটি নিয়েছে। যদিও, তালিকাভুক্ত সমস্ত ভাষার প্রাথমিক কারণ এটি অসম্ভব বলে মনে হচ্ছে, তবে সম্ভবত এটি এটি। সম্ভবত আমি কেবল সেই সংখ্যালঘুতে রয়েছি যারা সি ++ ডিস্ট্রাক্টরদের পছন্দ করে এবং অন্য কারও পক্ষে সত্যিই চিন্তা নেই, এটি বেশিরভাগ ভাষা ধ্বংসকারীদের বাস্তবায়ন না করার কারণ হতে পারে। তারা শুধু যত্ন নেই।
dbcb

2

এটি প্রশ্নের পুরো উত্তর নয়, তবে আমি এমন কয়েকটি পর্যবেক্ষণ যোগ করতে চেয়েছিলাম যা অন্যান্য উত্তর বা মন্তব্যে আওতাভুক্ত হয়নি।

  1. প্রশ্নটি স্পষ্টতই ধরে নিয়েছে যে আমরা একটি সিমুলা স্টাইলের অবজেক্ট ভিত্তিক ভাষা নিয়ে কথা বলছি যা নিজেই সীমাবদ্ধ। বেশিরভাগ ভাষায়, এমনকি বস্তুগুলির সাথেও, সমস্ত কিছুই একটি বস্তু নয়। ধ্বংসকারীদের বাস্তবায়নের জন্য যন্ত্রপাতিগুলি এমন একটি মূল্য চাপিয়ে দেবে যা প্রতিটি ভাষা প্রয়োগকারী প্রদান করতে রাজি নয়।

  2. সি ++ এর ধ্বংস আদেশ সম্পর্কে কিছু অন্তর্নিহিত গ্যারান্টি রয়েছে। আপনার যদি গাছের মতো ডেটা কাঠামো থাকে, উদাহরণস্বরূপ, শিশুরা পিতামাতার আগে ধ্বংস হয়ে যাবে। জিসি'ড ভাষায় এটি নয়, সুতরাং শ্রেণিবিন্যাসিক সংস্থানগুলি একটি অনির্দেশ্য ক্রমে প্রকাশ করা যেতে পারে। স্মৃতিবিহীন সংস্থানগুলির জন্য, এটি গুরুত্বপূর্ণ।


2

যখন দুটি সর্বাধিক জনপ্রিয় দুটি জিসি ফ্রেমওয়ার্ক (জাভা এবং। নেট) ডিজাইন করা হয়েছিল, তখন আমি মনে করি লেখকরা আশা করেছিলেন যে চূড়ান্তকরণ অন্যান্য সংস্থান ব্যবস্থাপনার প্রয়োজনীয়তা এড়াতে যথেষ্ট কার্যকরভাবে কাজ করবে। 100% নির্ভরযোগ্য এবং নির্মাতামূলক সংস্থান ব্যবস্থাপনার জন্য প্রয়োজনীয় সমস্ত বৈশিষ্ট্যগুলির প্রয়োজন না থাকলে ভাষা এবং কাঠামো ডিজাইনের অনেকগুলি দিকগুলি ব্যাপকভাবে সরল করা যায়। সি ++ তে, এর ধারণাগুলির মধ্যে পার্থক্য করা প্রয়োজন:

  1. পয়েন্টার / রেফারেন্স যা এমন কোনও বিষয় চিহ্নিত করে যা একচেটিয়াভাবে রেফারেন্সের ধারকের মালিকানাধীন, এবং যা কোনও পয়েন্টার / রেফারেন্স দ্বারা সনাক্ত করা যায় না যা সম্পর্কে মালিক জানেন না।

  2. পয়েন্টার / রেফারেন্স যা এমন একটি শেরেবল অবজেক্টকে চিহ্নিত করে যা একচেটিয়াভাবে কারও মালিকানাধীন নয়।

  3. পয়েন্টার / রেফারেন্স যা এমন কোনও বিষয় চিহ্নিত করে যা একচেটিয়াভাবে রেফারেন্সের ধারকের মালিকানাধীন , তবে যার কাছে "ভিউ" এর মাধ্যমে অ্যাক্সেসযোগ্য মালিকের ট্র্যাকিংয়ের কোনও উপায় নেই।

  4. পয়েন্টার / রেফারেন্স যা কোনও অবজেক্টকে চিহ্নিত করে যা এমন কোনও অবজেক্টের ভিউ সরবরাহ করে যা অন্য কারও মালিকানাধীন।

যদি কোনও জিসি ভাষা / ফ্রেমওয়ার্কটি রিসোর্স ম্যানেজমেন্ট সম্পর্কে উদ্বিগ্ন না হয় তবে উপরের সমস্তগুলি একক ধরণের রেফারেন্স দ্বারা প্রতিস্থাপন করা যেতে পারে।

চূড়ান্তকরণটি অন্যান্য রূপের সংস্থান ব্যবস্থাপনার প্রয়োজনীয়তা অপসারণ করবে এই ধারণাটি আমি নির্দোষ খুঁজে পাব, তবে এই ধরণের প্রত্যাশা সেই সময়ে যুক্তিসঙ্গত ছিল কি না, ইতিহাস থেকে দেখা গেছে যে চূড়ান্তকরণের চেয়ে অনেকগুলি ক্ষেত্রে যথাযথ সংস্থান পরিচালনার প্রয়োজন রয়েছে । আমি ভাবতে পেরেছি যে ভাষা / কাঠামো স্তরে মালিকানা স্বীকৃতি প্রদানের পুরষ্কারগুলি ব্যয়টিকে ন্যায়সঙ্গত করার পক্ষে যথেষ্ট হবে (জটিলতাটি কোথাও কোথাও বিদ্যমান থাকতে হবে, এবং ভাষা / কাঠামোতে সরানো ব্যবহারকারীর কোডকে সহজতর করবে) তবে বুঝতে পারি যে সেখানে উল্লেখযোগ্য রয়েছে নকশা একক "ধরণের" রেফারেন্স রাখার সুবিধা - এমন কিছু যা কেবল তখনই কাজ করে যদি ভাষা / কাঠামো রিসোর্স ক্লিনআপ সম্পর্কিত ইস্যুগুলিতে অজ্ঞেয় থাকে।


2

আবর্জনা সংগ্রহ করা ভাষাগুলিতে অবজেক্ট ডেস্ট্রাক্টর দৃষ্টান্ত কেন ব্যাপকভাবে অনুপস্থিত?

আমি একটি সি ++ পটভূমি থেকে এসেছি, তাই এই অঞ্চলটি আমার কাছে বিস্মিত।

সি ++ এর ডেস্ট্রাক্টর আসলে করে দুটি জিনিস একত্রিত করে। এটি র‌্যামকে মুক্ত করে এবং এটি সংস্থান আইডিকে মুক্ত করে।

অন্যান্য ভাষাসমূহ এই উদ্বেগকে আলাদা করে জিসিকে র‌্যাম মুক্ত করার দায়িত্বে রাখে এবং অন্য একটি ভাষা বৈশিষ্ট্য নিখরচায় সংস্থান আইডির দায় গ্রহণ করে।

আমি এটি অত্যন্ত অভাব বোধ করি যে এই ভাষাগুলি মেমরিকে পরিচালনা করার উপযুক্ত একমাত্র উত্স হিসাবে বিবেচনা করে।

জিসিগুলি সে সম্পর্কেই রয়েছে। তারা কেবল ডোনা একটি জিনিস এবং এটি আপনার স্মৃতিশক্তি শেষ না হয় তা নিশ্চিত করা। র‌্যাম যদি অসীম হয় তবে সমস্ত জিসিগুলি অবসর নেবে কারণ তাদের অস্তিত্বের কোনও প্রকৃত কারণ আর নেই।

সকেট, ফাইল হ্যান্ডলগুলি, অ্যাপ্লিকেশনের রাজ্যগুলির সম্পর্কে কী?

ভাষাগুলি দ্বারা সম্পদ আইডিকে মুক্ত করার বিভিন্ন উপায় সরবরাহ করতে পারে:

  • ম্যানুয়াল .CloseOrDispose()কোড জুড়ে ছড়িয়ে ছিটিয়ে

  • ম্যানুয়াল ম্যানুয়াল .CloseOrDispose()মধ্যে বিক্ষিপ্তfinally ব্লক"

  • ম্যানুয়াল "রিসোর্স ID অবরোধের" (অর্থাত using, with, try-সঙ্গে-সম্পদ , ইত্যাদি) যা স্বয়ংক্রিয়রূপে .CloseOrDispose()ব্লক পরে সম্পন্ন

  • গ্যারান্টিযুক্ত "রিসোর্স আইডি ব্লকস" যা.CloseOrDispose() ব্লকটি শেষ হওয়ার পরে স্বয়ংক্রিয়ভাবে চলে

অনেক ভাষা ম্যানুয়াল (গ্যারান্টিযুক্তের বিপরীতে) মেকানিজম ব্যবহার করে যা সংস্থার অব্যবস্থাপনার সুযোগ তৈরি করে। এই সাধারণ নোডজেএস কোডটি নিন:

require('fs').openSync('file1.txt', 'w');
// forget to .closeSync the opened file

.. যেখানে প্রোগ্রামার খোলা ফাইলটি বন্ধ করতে ভুলে গেছে।

যতক্ষণ প্রোগ্রাম চলতে থাকবে ততক্ষণ খোলা ফাইলটি লম্বা অবস্থায় আটকে থাকবে। এইচএক্সডি ব্যবহার করে ফাইলটি খোলার চেষ্টা করে এবং এটি করা যায় না তা যাচাই করে এটি যাচাই করা সহজ:

এখানে চিত্র বর্ণনা লিখুন

সি ++ ডিসস্ট্রাক্টরের মধ্যে রিসোর্স আইডির নিখরচায়তাও গ্যারান্টিযুক্ত। আপনি RAII নিশ্চিত "রিসোর্স ID অবরোধের", এখনো "রিসোর্স ID অবরোধের" অসদৃশ মত পরিচালনা মনে হতে পারে, সি ++ ভাষা হওয়া থেকে RAII ব্লক প্রদানের বস্তুর থামবে না ফাঁস , তাই RAII ব্লক কখনো হতে পারে সম্পন্ন


দেখে মনে হচ্ছে প্রায় সব আধুনিক আবর্জনা সংগ্রহ করা ভাষা যেমন ওওপি অবজেক্ট সমর্থন হিসাবে রুবি, জাভাস্ক্রিপ্ট / ইএস / / ইএস,, অ্যাকশনসক্রিপট, লুয়া ইত্যাদি সম্পূর্ণভাবে ধ্বংসকারীকে বাদ দেয় / দৃষ্টান্ত চূড়ান্ত করে। পাইথনটিকে শ্রেণিবদ্ধভাবে একমাত্র বলে মনে হয় __del__()। কেন?

কারণ উপরে বর্ণিত হিসাবে তারা অন্যান্য উপায়ে ব্যবহার করে রিসোর্স আইডিগুলি পরিচালনা করে।

ল্যাঙ্গুয়েজ ডিজাইনের সিদ্ধান্তগুলি কী কী যা এই ভাষাগুলি অবজেক্ট ডিসপ্লেতে কাস্টম লজিক চালানোর কোনও উপায়ই না রাখে?

কারণ উপরে বর্ণিত হিসাবে তারা অন্যান্য উপায়ে ব্যবহার করে রিসোর্স আইডিগুলি পরিচালনা করে।

শ্রেণীর বা শ্রেণীর মতো কাঠামোর সাথে কাস্টম ইনস্ট্যান্টেশন (কনস্ট্রাক্টর) পাশাপাশি কোনও ভাষাতে অবজেক্টের দৃষ্টান্তগুলির অন্তর্নিহিত ধারণা থাকবে, তবুও ধ্বংসটি সম্পূর্ণভাবে বাদ দেওয়া / কার্যকারিতা চূড়ান্ত করা হবে কেন?

কারণ উপরে বর্ণিত হিসাবে তারা অন্যান্য উপায়ে ব্যবহার করে রিসোর্স আইডিগুলি পরিচালনা করে।

আমি একটি সম্ভাব্য যুক্তি দেখতে পেয়েছিলাম যে ডেস্ট্রাক্টর / ফাইনালাইজার ভবিষ্যতে কোনও অনির্দিষ্ট সময় না আসা পর্যন্ত কল করতে পারে না, তবে এটি জাভা বা পাইথনকে কার্যকারিতা সমর্থন করা থেকে বিরত রাখেনি।

জাভাতে ডেস্ট্রাক্টর নেই।

জাভা ডক্স উল্লেখ :

তবে চূড়ান্ত করার স্বাভাবিক উদ্দেশ্যটি হ'ল বস্তুটি অপরিবর্তনীয়ভাবে বাতিল করার আগে ক্লিনআপ ক্রিয়া করা। উদাহরণস্বরূপ, কোনও ইনপুট / আউটপুট সংযোগ উপস্থাপন করে এমন কোনও অবজেক্টের চূড়ান্তকরণ পদ্ধতিটি স্থায়ীভাবে বাতিল করার পূর্বে সংযোগটি ভঙ্গ করার জন্য সুস্পষ্ট I / O লেনদেন সম্পাদন করতে পারে।

.. তবে রিসোর্স-আইডি ম্যানেজমেন্ট কোডের মধ্যে রাখাকে Object.finalizerমূলত একটি অ্যান্টি-প্যাটার্ন ( সিএফ। ) হিসাবে বিবেচনা করা হয় । পরিবর্তে এই কোডগুলি কল সাইটে লেখা উচিত।

অ্যান্টি-প্যাটার্ন ব্যবহার করে এমন লোকদের কাছে তাদের ন্যায্যতা হ'ল তারা কল সাইটে রিসোর্স-আইডিগুলি প্রকাশ করতে ভুলে যেতে পারেন । সুতরাং, তারা চূড়ান্ত ক্ষেত্রে এটি আবার করতে , ঠিক যদি।

অবজেক্ট চূড়ান্তকরণের কোনও ফর্মকে সমর্থন না করার মূল ভাষা নকশার কারণগুলি কী কী?

চূড়ান্তকরণকারীর জন্য অনেকগুলি ব্যবহারের কেস নেই কারণ সে সময়ের মধ্যে যখন কোনও বস্তুর সাথে কোনও শক্তিশালী উল্লেখ নেই, এবং যে সময়টির স্মৃতি স্মৃতি জিসির দ্বারা পুনরুদ্ধার করা হয় সেই সময়ের মধ্যে কোডের একটি টুকরো চালানোর জন্য।

সম্ভাব্য ব্যবহারের কেসটি হ'ল আপনি যখন জিসি দ্বারা অবজেক্টের মধ্যে সময়ের একটি লগ রাখতে চান এবং সেই সময়টির সাথে যখন বস্তুর আর কোনও দৃ strong় উল্লেখ থাকে না, যেমন:

finalize() {
    Log(TimeNow() + ". Obj " + toString() + " is going to be memory-collected soon!"); // "soon"
}

-1

ডাঃ ডবস আর্ট সি ++ এ এটার প্রতিফলন খুঁজে পেয়েছে যা আরও সাধারণ ধারণা পেয়েছে যে যুক্তি দেয় যে ধ্বংসকারীরা এমন একটি ভাষায় সমস্যাযুক্ত যেখানে তারা প্রয়োগ করা হয়। এখানে মোটামুটি ধারণা থেকে মনে হয় যে ধ্বংসকারীদের একটি প্রধান উদ্দেশ্য মেমরির অবনতি পরিচালনা করা এবং এটি সঠিকভাবে সম্পাদন করা শক্ত hard মেমরিটি টুকরোচকভাবে বরাদ্দ করা হয় তবে বিভিন্ন বস্তু সংযুক্ত হয়ে যায় এবং তারপরে অবলম্বনের দায়িত্ব / সীমানা এত পরিষ্কার হয় না।

সুতরাং কোনও আবর্জনা সংগ্রহকারী এর সমাধানটি বহু বছর আগে বিকশিত হয়েছিল, তবে আবর্জনা সংগ্রহ পদ্ধতি থেকে বেরিয়ে আসার ক্ষেত্রে (যে একটি ধারণাগত ধারণা যা বাস্তবায়িত করা শক্ত) এর উপর ভিত্তি করে নয়, তবে কালেক্টর হিসাবে পর্যায়ক্রমে চলমান, কিছুটা নির্বিঘ্নে, যখন অ্যাপ্লিকেশনটি "মেমরির চাপ" অনুভব করে (যেমন স্মৃতিশক্তি শেষ নয়)।

অন্য কথায়, একটি "নতুন অব্যবহৃত অবজেক্ট" এর নিছক মানুষের ধারণাটি আসলে কিছু উপায়ে একটি বিভ্রান্তিকর বিমূর্ততা যে কোনও বস্তু "তাত্ক্ষণিকভাবে" অব্যবহৃত হতে পারে না। অব্যবহৃত বস্তুগুলি কেবল আবর্জনা সংগ্রহের অ্যালগরিদম চালিয়ে "আবিষ্কার" করা যায় যা অবজেক্ট রেফারেন্স গ্রাফকে অতিক্রম করে এবং সেরা সম্পাদনকারী অ্যালগরিদমগুলি মাঝেমধ্যে চালিত হয়।

এটি সম্ভবত আরও ভাল আবর্জনা সংগ্রহের অ্যালগরিদমটি আবিষ্কারের অপেক্ষায় রয়েছে যা অবিলম্বে অব্যবহৃত অবজেক্টগুলিকে সনাক্ত করতে পারে, যা তত্ক্ষণাত ধারাবাহিক ধ্বংসকারী কলিং কোডের দিকে নিয়ে যেতে পারে, তবে সে অঞ্চলে বহু বছর গবেষণার পরেও এটি খুঁজে পাওয়া যায়নি।

ফাইল বা সংযোগগুলির মতো রিসোর্স ম্যানেজমেন্ট ক্ষেত্রগুলির সমাধানটিতে মনে হয় অবজেক্ট "পরিচালক" তাদের ব্যবহার হ্যান্ডেল করার চেষ্টা করে।


2
আকর্ষণীয় সন্ধান। ধন্যবাদ। লেখকের যুক্তি ভিত্তিতে ক্লাসের দৃষ্টান্তগুলি পাস করার কারণে ডেস্ট্রাস্টরকে ভুল সময়ে ডাকা হত যেখানে ক্লাসটির যথাযথ অনুলিপি নির্মাণকারী নেই (যা একটি আসল সমস্যা) based যাইহোক, আধুনিক গতিশীল ভাষাগুলিতে এই দৃশ্যটি আসলেই বিদ্যমান নয় কারণ সবকিছুই রেফারেন্সের দ্বারা পাস করা হয় যা লেখকের পরিস্থিতি এড়িয়ে চলে। যদিও এটি একটি আকর্ষণীয় দৃষ্টিভঙ্গি, তবে আমি মনে করি না যে এটি বেশিরভাগ আবর্জনা সংগ্রহ করা ভাষা কেন ডেস্ট্রাক্টর / চূড়ান্তকরণ কার্যকারিতা বাদ দিতে বেছে নিয়েছে explains
ডিবিসিবি

2
এই উত্তরটি ডঃ ডাবের নিবন্ধটিকে ভুল উপস্থাপন করেছে: নিবন্ধটি বিতর্ক করে না যে সাধারণভাবে ধ্বংসকারীরা সমস্যাযুক্ত। নিবন্ধটি আসলে এটি যুক্তিযুক্ত: মেমরি পরিচালনার আদিমগুলি গোটো স্টেটমেন্টের মতো, কারণ এগুলি উভয়ই সহজ তবে খুব শক্তিশালী। গোটো স্টেটমেন্টগুলি "যথাযথভাবে সীমাবদ্ধ নিয়ন্ত্রণ কাঠামোগুলি" (দেখুন: ডিজজটস্রায়) সবচেয়ে ভালভাবে আবদ্ধ হয় সেইভাবে, মেমরি পরিচালনার আদিমগুলি "যথাযথভাবে সীমাবদ্ধ ডেটা স্ট্রাকচারগুলিতে" সেরাভাবে এনক্যাপুলেটেড হয়। ধ্বংসকারীরা এই দিকের এক ধাপ, তবে যথেষ্ট নয়। সত্য কিনা তা নিজের জন্য সিদ্ধান্ত নিন।
kdbanman
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.