আমার প্রোগ্রামটির আজীবন যদি আমার একটি টুকরো স্মৃতি ব্যবহার করার প্রয়োজন হয় তবে প্রোগ্রাম শেষ হওয়ার আগেই কি এটিকে মুক্ত করা সত্যিই প্রয়োজন?


67

অনেকগুলি বই এবং টিউটোরিয়ালে আমি মেমরি পরিচালনার অনুশীলন শুনেছি এবং চাপ অনুভব করেছি এবং অনুভব করেছি যে আমি যদি ব্যবহারের পরে স্মৃতি মুক্ত না করি তবে কিছু রহস্যজনক এবং ভয়ঙ্কর কিছু ঘটবে।

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

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

এখন, আমি সম্মত হই যে এই প্রশ্নটি আপনার পক্ষে কীভাবে আপনার মেমরি পরিচালনা করতে হবে তার ভিত্তিতে আপনি কতটা মেমরি প্রয়োজন এবং যখন আপনার এটির প্রয়োজন হবে তার ভিত্তিতে এই প্রশ্নটি প্রসারিত, তাই আমি এই প্রশ্নের ব্যাপ্তিটি এটিকে সংকীর্ণ করব: যদি আমার কোনও টুকরো ব্যবহার করার প্রয়োজন হয় আমার প্রোগ্রামের আজীবন স্মৃতি, প্রোগ্রাম সমাপ্তির আগে এটিকে মুক্ত করা কি সত্যই দরকার?

সম্পাদনা: অনুলিপি হিসাবে প্রস্তাবিত প্রশ্নটি অপারেটিং সিস্টেমের ইউনিক্স পরিবারের জন্য নির্দিষ্ট। এমনকি এর শীর্ষ উত্তর এমনকি লিনাক্সের জন্য নির্দিষ্ট একটি সরঞ্জাম নির্দিষ্ট করেছে (যেমন: ভ্যালগ্রিন্ড)। এই প্রশ্নটি বেশিরভাগ "নরমাল" অ-এম্বেড থাকা অপারেটিং সিস্টেমগুলিকে আচ্ছাদন করার জন্য এবং কোনও প্রোগ্রামের আজীবন প্রয়োজন মেমরি মুক্ত করার জন্য এটি কেন একটি ভাল অনুশীলন বা নয়।



19
আপনি এই ভাষাটি অজ্ঞেহিতকে ট্যাগ করেছেন তবে অনেক ভাষায় (যেমন জাভা) ম্যানুয়ালি মেমরি মুক্ত করার প্রয়োজন নেই; কোনও বস্তুর সর্বশেষ রেফারেন্স সুযোগের বাইরে চলে যাওয়ার কিছু পরে এটি স্বয়ংক্রিয়ভাবে ঘটে
রিচার্ড টিঙ্গল

3
এবং অবশ্যই আপনি কোনও একক মোছা ছাড়াই সি ++ লিখতে পারেন এবং এটি মেমরির জন্য ঠিক থাকবে
নিককো

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

4
আপনি লিখেছেন: "কার্নেলটি মূলত প্রোগ্রামটি শেষ হওয়ার পরে সমস্ত সম্পদ [...] পরিষ্কার করার গ্যারান্টিযুক্ত"। এটি সাধারণত মিথ্যা, কারণ সমস্ত কিছুই মেমরি, হ্যান্ডেল বা কার্নেল অবজেক্ট নয়। তবে এটি মেমরির ক্ষেত্রে সত্য, যার সাথে আপনি তত্ক্ষণাত আপনার প্রশ্নকে সীমাবদ্ধ করে রেখেছেন।
এরিক টাওয়ার

উত্তর:


108

আমার প্রোগ্রামটির আজীবন যদি আমার একটি টুকরো স্মৃতি ব্যবহার করার প্রয়োজন হয় তবে প্রোগ্রাম শেষ হওয়ার আগেই কি এটিকে মুক্ত করা সত্যিই প্রয়োজন?

এটি বাধ্যতামূলক নয়, তবে এর সুবিধাগুলিও থাকতে পারে (পাশাপাশি কিছু ত্রুটিও)।

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

যাইহোক, কার্যকরভাবে মৃত্যুদন্ডের শেষে সমস্ত মেমরি স্পষ্টভাবে প্রকাশ করে,

  • ডিবাগিং / পরীক্ষার সময়, মেম ফাঁস সনাক্তকরণ সরঞ্জামগুলি আপনাকে "মিথ্যা ধনাত্মক" প্রদর্শন করবে না
  • কোডটি বরাদ্দকরণ এবং ডিএলোকেশনের সাথে একত্রে একটি পৃথক উপাদান হিসাবে সরিয়ে নিয়ে মেমোরি ব্যবহার করে এমন কোডটি সরানো এবং পরে এটি অন্য কোনও প্রসঙ্গে ব্যবহার করা যেতে পারে যেখানে মেমরির ব্যবহারের সময়টি উপাদানটির ব্যবহারকারীর দ্বারা নিয়ন্ত্রণ করা দরকার

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

আরও সাধারণভাবে, বরাদ্দকরণ এবং সম্পর্কিত deallocating কোডটি সবসময় যুগলভাবে অনেক প্রোগ্রামারদের মধ্যে একটি "ভাল অভ্যাস" হিসাবে গণনা করা হয়: সর্বদা এটি করার দ্বারা, আপনি স্মৃতিমুক্ত থাকতে হবে এমন পরিস্থিতিতে ডিএলোকেশন কোড ভুলে যাওয়ার সম্ভাবনা হ্রাস করবেন ।


12
ভাল প্রোগ্রামিং অভ্যাস বিকাশ সম্পর্কে ভাল পয়েন্ট।
লরেন্স

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

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

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

3
অতিরিক্তভাবে, যদি প্রোগ্রামটির পুরো জীবনকালের জন্য মেমরিটির সত্যিকার অর্থে উপস্থিত থাকার প্রয়োজন হয়, তবে স্ট্যাকের উপর একটি কাঠামো তৈরির জন্য এটি বোধগম্য বিকল্প হতে পারে, যেমন main
কাইল স্ট্র্যান্ড

11

একটি প্রোগ্রাম চালানো শেষে মেমরি মুক্ত করা কেবলমাত্র সিপিইউয়ের অপচয় করা। এটি ঘরকে কক্ষপথ থেকে কটাক্ষ করার আগে পরিপাটি করার মতো।

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

এর একটি চতুর সমাধান হ'ল "টেলোক" যা আপনাকে মেমরির বরাদ্দগুলির একটি প্রচুর পরিমাণ তৈরি করতে দেয় এবং তারপরে সেগুলি সমস্ত একটি কল দিয়ে ফেলে দেয়।


1
ধরে নিচ্ছি যে আপনি জানেন যে আপনার ওএসের নিজস্ব লিক নেই।
ডাব্লুগ্রোলাও

5
"সিপিইউ সময় নষ্ট" যদিও সময় খুব খুব কম পরিমাণে। freeসাধারণত তুলনায় অনেক দ্রুত malloc
পল ড্রাগার

@ পলড্রাপার আই, সময় নষ্ট করে সব কিছু আবার বদলানো আরও তাত্পর্যপূর্ণ।
উত্সাহকটি

5

আপনি আবর্জনা সংগ্রহের সাথে কোনও ভাষা ব্যবহার করতে পারেন (যেমন স্কিম, ওকামল, হাস্কেল, কমন লিস্প এবং এমনকি জাভা, স্কালা, ক্লোজার)।

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

আপনি সিটিতে কোডযুক্ত আপনার প্রোগ্রামের জন্য (বা এমনকি সি ++) বোহেমের রক্ষণশীল আবর্জনা সংগ্রহকারীও ব্যবহার করতে পারেন । এর পরে আপনি আপনার সমস্ত প্রতিস্থাপন করবে mallocসঙ্গে GC_malloc এবং প্রায় মাথা ঘামান না freeকোনো পয়েন্টার -ing। অবশ্যই আপনাকে বোহেমের জিসি ব্যবহারের উপকারিতা এবং সুরক্ষাগুলি বুঝতে হবে। জিসির হ্যান্ডবুকটিও পড়ুন ।

মেমরি পরিচালনা একটি প্রোগ্রামের একটি বিশ্বব্যাপী সম্পত্তি global কোনও কোনও উপায়ে এটি (এবং কিছু প্রদত্ত ডেটার প্রাণবন্ততা) একটি সম্পূর্ণ প্রোগ্রামের সম্পত্তি হওয়ায় এটি অ-গঠনমূলক এবং অ-মডুলার।

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

আমার প্রোগ্রামটির আজীবন যদি আমার একটি টুকরো স্মৃতি ব্যবহার করার প্রয়োজন হয় তবে প্রোগ্রাম শেষ হওয়ার আগেই কি এটিকে মুক্ত করা সত্যিই প্রয়োজন?

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

লক্ষ্য করুন যে সিস্টেমটি freeপ্রায়শই ওএসের কাছে মেমরি ছেড়ে দেয় না (যেমন পসিক্স সিস্টেমে মুনম্যাপ (২) কল করে) তবে সাধারণত একটি স্মৃতি অঞ্চলকে ভবিষ্যতে পুনরায় ব্যবহারযোগ্য হিসাবে চিহ্নিত করে malloc। বিশেষত, ভার্চুয়াল অ্যাড্রেস স্পেস (যেমন /proc/self/mapsলিনাক্সের মাধ্যমে দেখা , প্রোক (5) দেখুন ....) পরে সঙ্কুচিত না হতে পারে free(সুতরাং আপনার প্রসেসের জন্য একই পরিমাণে ব্যবহৃত মেমরির মতো ইউটিলিটিগুলি psবা topরিপোর্ট করছে)।


3
"কখনও কখনও, কিছু মান চূড়ান্ত করা যেতে পারে, উদাহরণস্বরূপ, জিসি এবং রানটাইম সিস্টেম একটি ফাইল হ্যান্ডেল মানটি বন্ধ করে দেয় যখন সেই মানটি অ্যাক্সেসযোগ্য হয়" আপনি জোর দিয়ে বলতে পারেন যে বেশিরভাগ জিসিড ভাষায় কোনও স্মৃতি কখনও পুনরুদ্ধার হওয়ার কোনও গ্যারান্টি নেই nor যে কোনও ফাইনালাইজার কখনও চলতে পারে, প্রস্থান এমনকি: প্রস্থানকালেও: stackoverflow.com/questions/7880569/…
ডিসিপ্লিকেটর

আমি ব্যক্তিগতভাবে এই উত্তরটিকে প্রাধান্য দিই, কারণ এটি আমাদের জিসি (অর্থাত্ একটি আরও স্বয়ংক্রিয় পদ্ধতি) ব্যবহার করে উত্সাহ দেয়।
তা থানাহ দিনহ

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

3

এটি প্রয়োজনীয় নয় , যেমন আপনি ব্যর্থ হলে আপনার প্রোগ্রামটি যথাযথভাবে কার্যকর করতে ব্যর্থ হবেন না। তবে, সুযোগ পেলে আপনি বেছে নিতে পারেন এমন কয়েকটি কারণ রয়েছে।

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

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

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


1

যে কোনও ভাষায় আপনি ম্যানুয়ালি ম্যানুয়ালি মুক্ত করেন না এমন ভাষাগুলি উপেক্ষা করে ...

আপনি এই মুহূর্তে "একটি প্রোগ্রাম" হিসাবে যা ভাবেন সেগুলি কোনও কোনও সময়ে কেবল একটি ফাংশন বা পদ্ধতিতে পরিণত হতে পারে যা বৃহত্তর প্রোগ্রামের অংশ। এবং তারপরে সেই ফাংশনটি একাধিকবার কল হতে পারে। এবং তারপরে মেমরি যে আপনার "ম্যানুয়ালি মুক্ত" হওয়া উচিত তা মেমরি ফাঁস হবে। এটি অবশ্যই রায় আহ্বান।


2
এটি কেবল কয়েক ঘন্টা আগে পোস্ট করা শীর্ষের উত্তরে তৈরি করা (এবং আরও ভালভাবে ব্যাখ্যা করা হয়েছে) পুনরাবৃত্তি বলে মনে হচ্ছে : "বরাদ্দ এবং ডিওলোকেশন সহ স্মৃতি ব্যবহার করে এমন কোডটি একটি পৃথক উপাদানগুলিতে সরানো এবং পরে এটি ব্যবহার করা কোডটি আরও সহজতর হতে পারে later ভিন্ন প্রসঙ্গে যেখানে মেমোরির জন্য ব্যবহারের সময়টি উপাদানটির ব্যবহারকারীর দ্বারা নিয়ন্ত্রণ করা দরকার ... "
gnat

1

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

এগুলি সম্পর্কে আপনার বোঝাপড়া টাটকা থাকা অবস্থায় এমন কিছু করুন।

এটি একটি ছোট বিনিয়োগ যা ভবিষ্যতে বড় আয় করতে পারে।


2
এটি পূর্বের 11 টি উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির তুলনায় যথেষ্ট কিছু যুক্ত করবে বলে মনে হচ্ছে না। বিশেষত, ভবিষ্যতে সম্ভবত প্রোগ্রামটির পরিবর্তন সম্পর্কে পয়েন্টটি ইতিমধ্যে তিন বা চারবার করা হয়েছে
gnat

1
@ জাগ্রত একটি সংশ্লেষিত এবং অস্পষ্ট উপায়ে - হ্যাঁ। একটি পরিষ্কার বিবৃতিতে - না। আসুন গতিবেগ নয়, উত্তর মানের উপর ফোকাস করা যাক।
এজেন্ট_এল

1
গুণমান অনুসারে, শীর্ষের উত্তরটি এই পয়েন্টটি ব্যাখ্যা করার ক্ষেত্রে আরও ভাল বলে মনে হচ্ছে
gnat

1

না, এটি প্রয়োজনীয় নয়, তবে এটি একটি ভাল ধারণা।

আপনি বলেছিলেন যে আপনি মনে করেন যে "রহস্যজনক এবং ভয়ঙ্কর জিনিসগুলি ঘটতে পারে যদি আমি স্মৃতিটি ব্যবহার না করে এটি ব্যবহার না করি" "

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

অবশ্যই এতে আরও যুক্ত সুবিধা রয়েছে যা আপনার কোডটি আরও সহজে ব্যবহার করা যায় এবং আরও সহজে অভিযোজিত হতে পারে, যেমন অন্যরা বলেছেন।

তবে , অন্তত একটি ক্ষেত্রে রয়েছে যেখানে প্রোগ্রাম সমাপ্তির ঠিক আগে মেমরি মুক্ত না করাই ভাল ।

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

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

এটি লক্ষণীয় যে একটি ওও ভাষায়, কোনও অবজেক্টের ডেস্ট্রাক্টরকে কল করাও স্মৃতিটিকে সরিয়ে নিতে বাধ্য করবে; আপনার যদি এটি করতে হয় তবে আপনি স্মৃতিশক্তিও মুক্ত করতে পারেন।


1
পেজ-আউট মেমরিটি ডিলেক্ট করার জন্য পেজড আউট মেমরির প্রয়োজন হয় এমন ধারণাকে সমর্থন করার জন্য আপনি কিছু উদ্ধৃত করতে পারেন? এটি স্পষ্টতই অদক্ষ, অবশ্যই আধুনিক ওএস এর চেয়ে স্মার্ট!

1
সমস্ত ট্রেডের জোন, আধুনিক ওএসগুলি স্মার্ট, তবে বিদ্রূপজনকভাবে বেশিরভাগ আধুনিক ভাষা এটি নয়। যখন আপনি মুক্ত (কিছু), সংকলক স্ট্যাকের উপর "কিছু" লাগিয়ে দেবে, তারপরে ফ্রি () কল করুন। এটিকে স্ট্যাকের উপরে রাখার জন্য যদি এটি অদলবদল হয় তবে এটিকে আবার র‍্যামে বদলে নেওয়া দরকার।
জেফিকিন্স

@ জোনফএলট্রেডস একটি ফ্রি-লিস্টের সেই প্রভাব ফেলবে, যদিও এটি বেশ অপ্রচলিত মলোক বাস্তবায়ন। তবে ওএস আপনাকে এ জাতীয় বাস্তবায়ন ব্যবহার করা থেকে বিরত রাখতে পারে না।

0

ম্যানুয়ালি পরিষ্কার করার প্রধান কারণগুলি হ'ল: আপনি মেমোরি ব্লকের জন্য একটি খাঁটি মেমরি ফাঁসের ভুল হওয়ার সম্ভাবনা কম যা কেবল প্রস্থান করার সময় পরিষ্কার হয়ে যাবে, আপনি যখন পুরো ডেটা কাঠামোটি অনুসরণ করেন তখনই আপনি কখনও কখনও বরাদ্দকারী বাগগুলি খুঁজে পাবেন to এটিকে হ্রাস করুন, এবং আপনি যদি কখনও রিফ্যাক্টর করেন তবে আপনার কিছুটা মাথা ব্যথার প্রয়োজন হবে যাতে প্রোগ্রামটি প্রস্থান হওয়ার আগে কোনও বস্তুর অবনতি ঘটে

ম্যানুয়ালি পরিষ্কার না করার মূল কারণগুলি হ'ল: আপনার অপ্রয়োজনীয় ক্লিন-আপ কোডে পারফরম্যান্স, পারফরম্যান্স, পারফরম্যান্স এবং কোনও ধরণের ফ্রি-দ্বিগুণ বা ব্যবহারের পরে ফ্রি বাগ, যা ক্রাশ বাগ বা সুরক্ষায় রূপান্তর করতে পারে গ্রহণকারী।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.