লিঙ্কযুক্ত নোড কাঠামোটি অপরিবর্তনীয় হওয়ার জন্য কি কোনও ব্যবহারিক উপায় আছে?

Question

আমি এককভাবে লিঙ্কযুক্ত তালিকাটি লেখার সিদ্ধান্ত নিয়েছি এবং অভ্যন্তরীণ সংযুক্ত নোড কাঠামোটিকে অচল করার জন্য পরিকল্পনা নিয়েছিলাম।

যদিও আমি ছিনতাই করেছিলাম। বলুন আমার কাছে নিম্নলিখিত লিঙ্কযুক্ত নোড রয়েছে (পূর্ববর্তী addক্রিয়াকলাপ থেকে ):

1 -> 2 -> 3 -> 4

এবং বলুন আমি একটি সংযুক্ত করতে চাই 5।

এটি করার জন্য, যেহেতু নোড 4অপরিবর্তনীয়, তাই আমার একটি নতুন অনুলিপি তৈরি করা দরকার 4, তবে এর nextক্ষেত্রটি একটি নতুন নোডের সাথে প্রতিস্থাপন করতে হবে 5। সমস্যা এখন, 3পুরানো উল্লেখ করা হয় 4; সংযুক্ত ছাড়া একটি 5। এখন আমার অনুলিপি করা দরকার 3, এবং অনুলিপিটির nextরেফারেন্সের জন্য এর ক্ষেত্রটি প্রতিস্থাপন করা উচিত 4, তবে এখন 2পুরনো উল্লেখ করা হচ্ছে 3...

বা অন্য কথায়, একটি সংযোজন করতে, পুরো তালিকাটি অনুলিপি করা দরকার বলে মনে হচ্ছে।

আমার প্রশ্নগুলো:

• আমার চিন্তা কি সঠিক? পুরো কাঠামোটি অনুলিপি না করে কোনও অ্যাপেনড করার কোনও উপায় আছে কি?

• স্পষ্টতই "কার্যকর জাভা" তে পুনরুদ্ধার রয়েছে:

  শ্রেণিগুলিকে পরিবর্তনযোগ্য করা উচিত যদি না তাদের পক্ষে পরিবর্তনীয় করার জন্য খুব ভাল কারণ থাকে ...

  এটা কি মিউচ্যালিটির জন্য ভাল কেস?

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

Comments

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

— ছটফট করে তোলে

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

— রওয়ং

সম্পর্কিত (সম্ভবত একটি সদৃশ): সংগ্রহ অবজেক্ট কি আরও ভাল অপরিবর্তনীয়? "পারফরম্যান্স ওভারহেড ব্যতীত এই সংগ্রহটি (ক্লাস লিংকডলিস্ট) কি অপরিবর্তনীয় সংগ্রহ হিসাবে চালু করা যেতে পারে?"

— gnat

আপনি কেন একটি অপরিবর্তনীয় লিঙ্ক তালিকা তৈরি করবেন? লিঙ্কযুক্ত তালিকার সর্বাধিক সুবিধা হ'ল রূপান্তরতা, আপনি কি অ্যারে দিয়ে ভাল থাকবেন না?

— পিটার বি

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

— নাল

Answer 1

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

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

কেন প্রিপেন্ডিংয়ের পুরো তালিকাটি অনুলিপি করার প্রয়োজন হয় না তার একটি উদাহরণ হিসাবে আপনার বিবেচনা করুন:

2 -> 3 -> 4

একটি প্রস্তুতি 1আপনাকে দেয়:

1 -> 2 -> 3 -> 4

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

Comments

আহ্, কেন প্রিপেন্ডিংয়ের জন্য একটি অনুলিপি লাগবে না; আমি এটা ভাবিনি।

— কারসিজিনিট

Answer 2

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

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

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

list.append(x);
list.prepend(y);

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

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

Answer 3

যদি আপনার একক লিঙ্কযুক্ত তালিকা থাকে তবে আপনি যদি পিছনের দিকের চেয়ে আরও বেশি কিছু করেন তবে আপনি সম্মুখভাগে কাজ করবেন।

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

Comments

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

— কারসিজিনিট

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

— রাচেট ফ্রিক

জাভডোকস স্পষ্টভাবে "সংযোজন" শব্দটি ব্যবহার করে। আপনি বলছেন বাস্তবায়নের স্বার্থে এটিকে অগ্রাহ্য করা ভাল?

— কারসিজেনিকেট

@ কারসিজেনিকেট না আমি বলছি যে একটানা লিঙ্কযুক্ত তালিকাকে অপরিবর্তনীয় নোডের সাথে ছাঁচে ফেলার জন্য ভুল হয়েছেjava.util.List

— র‌্যাচেট ফ্রিক

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

— রওয়ং

Answer 4

অন্যরা যেমন উল্লেখ করেছে, আপনি সঠিক যে একটি অপরিবর্তনীয় একক-লিঙ্কযুক্ত তালিকার জন্য অ্যাপেনড ক্রিয়াকলাপ সম্পাদন করার সময় পুরো তালিকাটি অনুলিপি করা প্রয়োজন।

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

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

একটি অপরিবর্তনীয় DListশ্রেণি প্রয়োগ করা খুব সহজ হওয়া উচিত যা হাস্কেলের মতো অনুরূপ ইন্টারফেস সরবরাহ করে Data.DList।

Answer 5

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

একটি প্রতিক্রিয়া টিউটোরিয়াল থেকে আসা এই চিত্রটি আমার ভাঙ্গা ইংরাজির চেয়ে পরিষ্কার হতে পারে:

Answer 6

এটি কঠোরভাবে জাভা নয়, তবে আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি এই নিবন্ধটি অপরিবর্তনীয়, তবে পারফরম্যান্ট ইনডেক্সযুক্ত ধ্রুবক ডেটা কাঠামোতে পড়বেন:

http://www.codecommit.com/blog/scala/implementing-persistent-vectors-in-scala

যেহেতু এটি একটি স্কালা ডেটা কাঠামো, তাই এটি জাভা থেকেও ব্যবহার করা যেতে পারে (আরও কিছুটা ভার্বোসিটির সাথে)। এটি ক্লোজুরে উপলভ্য ডেটা স্ট্রাকচারের উপর ভিত্তি করে এবং আমি নিশ্চিত যে আরও একটি "নেটিভ" জাভা গ্রন্থাগার এটিও সরবরাহ করছে।

এছাড়াও, একটি নোট নির্মাণের অপরিবর্তনীয় ডাটা স্ট্রাকচার: "নির্মাতা", যা আপনি "পরিবর্তন ঘটান" আপনার "এর অধীনে নির্মাণাধীন" এটা উপাদান (একটি একক থ্রেড মধ্যে) সংযোজন করে ডাটা স্ট্রাকচার করতে পারবেন কিছু বাছাই আপনি সাধারণত চাই; আপনি সংযোজন সম্পন্ন করার পরে, আপনি "আন্ডার-কনস্ট্রাকশন" অবজেক্টের মতো একটি পদ্ধতি কল করেন যেমন .build()বা .result()যা "অবজেক্ট" তৈরি করে যা আপনাকে একটি অপরিবর্তনীয় ডেটা কাঠামো দেয় যা আপনি নিরাপদে ভাগ করতে পারবেন।

Comments

সেখানে PersistentVector জাভা পোর্ট সম্পর্কে একটি প্রশ্ন আছে stackoverflow.com/questions/15997996/...

— James_pic

Answer 7

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

ফরোয়ার্ড-তালিকায় একটি আইটেম প্রস্তুত করা বা বিপরীত তালিকায় একটি আইটেম যুক্ত করার জন্য কেবল একটি নতুন নোড তৈরি করা দরকার যা finalরেফারেন্স দ্বারা চিহ্নিত নোডের সাথে সংযোগ স্থাপন করে এবং একই ধরণের একটি নতুন তালিকা অবজেক্টটি মূল হিসাবে একটি finalরেফারেন্স সহ তৈরি করতে হবে যে নতুন নোডে

ফরোয়ার্ড-তালিকায় একটি আইটেম যুক্ত করা বা বিপরীত তালিকায় প্রিপেন্ড করাতে বিপরীত ধরণের একটি তালিকা থাকা প্রয়োজন; প্রথমবার যা কোনও নির্দিষ্ট তালিকার সাথে করা হয় এটির বিপরীতে একটি নতুন অবজেক্ট তৈরি করা উচিত এবং একটি রেফারেন্স সংরক্ষণ করা উচিত; ক্রিয়াটি পুনরাবৃত্তি করা উচিত তালিকাটি পুনরায় ব্যবহার করা উচিত।

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

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