আমার প্রশ্নটি আগে জিজ্ঞাসিত এই প্রশ্নের সাথে সম্পর্কিত । আমি যে পরিস্থিতিতে উত্পাদক এবং ভোক্তা থ্রেডের মধ্যে যোগাযোগের জন্য একটি সারি ব্যবহার করছি সেখানে লোকেরা সাধারণত ব্যবহারের পরামর্শ দেয় LinkedBlockingQueueবা ConcurrentLinkedQueue?
একে অপরকে ব্যবহার করার সুবিধা / অসুবিধাগুলি কী?
আমি একটি এপিআই দৃষ্টিকোণ থেকে প্রধান পার্থক্যটি হ'ল একটি হ'ল LinkedBlockingQueueoptionচ্ছিকভাবে সীমাবদ্ধ।
উত্তর:
প্রযোজক / গ্রাহক থ্রেডের জন্য, আমি নিশ্চিত নই যে ConcurrentLinkedQueueএটি এমনকি একটি যুক্তিসঙ্গত বিকল্প - এটি বাস্তবায়ন করে না BlockingQueue, যা প্রযোজক / গ্রাহক সারি আইএমওর জন্য মূল ইন্টারফেস। আপনাকে ফোন করতে হবে poll(), যদি আপনি কিছু না পেয়ে থাকেন তবে কিছুক্ষণ অপেক্ষা করুন এবং তারপরে আবার জরিপ করুন ইত্যাদি ... নতুন আইটেম এলে বিলম্ব হয় এবং শূন্য হলে অদক্ষতা (ঘুম থেকে অকারণে জেগে ওঠার কারণে) ।
ব্লকিংকুইয়ের জন্য দস্তাবেজগুলি থেকে:
BlockingQueueবাস্তবায়নগুলি প্রাথমিকভাবে উত্পাদক-ভোক্তা সারিগুলির জন্য ব্যবহার করার জন্য ডিজাইন করা হয়েছে
আমি জানি এটি কঠোরভাবে বলতে পারে না যে কেবলমাত্র ব্লক করা সারিগুলি প্রযোজক-ভোক্তা সারিগুলির জন্য ব্যবহার করা উচিত, তবে তবুও ...
ConcurrentLinkedQueueযদি আপনার থ্রেড একাধিক সারি পরীক্ষণ এছাড়াও দরকারী। উদাহরণস্বরূপ, একটি বহু-ভাড়াটে সার্ভারে। বিচ্ছিন্নতার কারণে ধরে নেওয়া আপনি এর পরিবর্তে কোনও একক ব্লকিং সারি এবং ভাড়াটে বৈষম্যমূলক ব্যবহার করবেন না।
take()এবং put()কেবলমাত্র অতিরিক্ত সংস্থান (সিঙ্ক্রোনাইজেশনের অন্তর্বর্তী) ব্যয় করি ConcurrentLinkedQueue । যদিও প্রযোজক-ভোক্তা পরিস্থিতিগুলির
এই প্রশ্নটি আরও ভাল উত্তর প্রাপ্য।
জাভা ম্যাগেড এম এম মাইকেল এবং মাইকেল এল স্কট- র অ-ব্লকিং লক-মুক্ত সারির জন্য ConcurrentLinkedQueueবিখ্যাত অ্যালগরিদমের উপর ভিত্তি করে তৈরি ।
একটি বিতর্কিত সংস্থান (আমাদের সারি) জন্য এখানে একটি শব্দ হিসাবে "অ-ব্লকিং" এর অর্থ প্ল্যাটফর্মের সময়সূচী যা করে তা বিবেচনা না করেই, কোনও থ্রেড বাধা দেওয়ার মতো, বা যদি প্রশ্নটির থ্রেড খুব ধীর গতির হয়, তবে অন্য থ্রেড একই উত্সটির পক্ষে লড়াই করছে এখনও অগ্রগতি করতে সক্ষম হবে। উদাহরণস্বরূপ যদি কোনও লক জড়িত থাকে তবে লকযুক্ত থ্রেডটি বাধাগ্রস্থ হতে পারে এবং সেই লকের জন্য অপেক্ষা করা সমস্ত থ্রেড অবরুদ্ধ করা হবে। synchronizedজাভাতে অন্তর্নিহিত লকগুলি ( কীওয়ার্ড) এছাড়াও পারফরম্যান্সের জন্য কঠোর শাস্তির সাথে আসতে পারে - যেমন পক্ষপাতদুষ্ট লক করার সময়জড়িত রয়েছে এবং আপনার বিতর্ক রয়েছে, বা কোনও ভিএম স্পিনের অনুগ্রহকালীন সময় পরে লকটিকে "স্ফীত" করার পরে এবং বিতর্কিত থ্রেডগুলি ব্লক করার পরে ... এই কারণেই অনেকগুলি প্রসঙ্গে (কম / মধ্যম বিতর্কিত পরিস্থিতি) তুলনা করা এবং - পারমাণবিক রেফারেন্সে সেটগুলি আরও কার্যকর হতে পারে এবং অনেকগুলি অ-ব্লক করা ডেটা-স্ট্রাকচারগুলি ঠিক এটিই করে।
জাভা ConcurrentLinkedQueueকেবল অ-ব্লকিং নয়, তবে এর দুর্দান্ত পণ্য রয়েছে যা নির্মাতা গ্রাহকের সাথে লড়াই করে না। একটি একক প্রযোজক / একক গ্রাহক দৃশ্যে (এসপিএসসি), এর সত্যিকার অর্থেই এর মানে হল যে কোনও মতবিরোধ থাকবে না। একাধিক প্রযোজক / একক গ্রাহক দৃশ্যে, গ্রাহক প্রযোজকদের সাথে বিতর্ক করবেন না। একাধিক প্রযোজক চেষ্টা করার সময় এই কাতারে বিতর্ক রয়েছে offer()তবে সংজ্ঞা অনুসারে এটি সম্মতিযুক্ত। এটি মূলত একটি সাধারণ উদ্দেশ্য এবং দক্ষ নন-ব্লকিং সারি।
এটি একটি হিসাবে BlockingQueueভাল না, একটি সারিতে অপেক্ষা করার জন্য একটি থ্রেড ব্লক করা সমকালীন সিস্টেমগুলি ডিজাইনের একটি অদ্ভুত ভয়ঙ্কর উপায়। না। আপনি যদি ConcurrentLinkedQueueকোনও ভোক্তা / প্রযোজক দৃশ্যে কীভাবে ব্যবহার করবেন তা অনুভব করতে না পারেন , তবে কেবল ভাল অভিনেতার কাঠামোর মতো উচ্চ স্তরের বিমূর্তিগুলিতে স্যুইচ করুন।
LinkedBlockingQueueসারিটি খালি বা পূর্ণ হলে গ্রাহক বা উত্পাদককে অবরুদ্ধ করে এবং সংশ্লিষ্ট গ্রাহক / প্রযোজক থ্রেডকে ঘুমিয়ে দেওয়া হয়। তবে এই ব্লকিং বৈশিষ্ট্যটি একটি ব্যয় সহ আসে: উত্পাদক বা ভোক্তাদের (প্রতিটি যদি হয়) প্রতিটি পুট বা নেওয়া অপারেশন লক হয়, তাই অনেক উত্পাদক / গ্রাহকের সাথে পরিস্থিতিগুলিতে অপারেশনটি ধীর হতে পারে।
ConcurrentLinkedQueueলক ব্যবহার করছে না, কিন্তু সিএএস , তার প্রয়োগ / গ্রহণের অপারেশনগুলিতে অনেকগুলি উত্পাদক এবং গ্রাহক থ্রেডের সাথে ঝুঁকি হ্রাস করে। তবে "ওয়েট ফ্রি" ডেটা স্ট্রাকচার ConcurrentLinkedQueueহওয়ায় খালি থাকলে তা আটকাবে না, অর্থাত্ গ্রাহককে "ব্যস্ত ওয়েটিং" দ্বারা take()প্রত্যাবর্তন nullমূল্যের সাথে মোকাবিলা করতে হবে , উদাহরণস্বরূপ, ভোক্তা থ্রেডটি সিপিইউ খেয়ে ফেলবে।
কোনটি "ভাল" সেগুলি গ্রাহক থ্রেডের সংখ্যার উপর নির্ভর করে, তারা যে পরিমাণ গ্রাহ্য করে / উত্পাদন করে ইত্যাদি each প্রতিটি দৃশ্যের জন্য একটি মানদণ্ডের প্রয়োজন।
একটি নির্দিষ্ট ব্যবহারের ক্ষেত্রে যেখানে ConcurrentLinkedQueueস্পষ্টতই ভাল তা হ'ল উত্পাদকরা যখন প্রথমে কিছু উত্পাদন করে এবং কাজটিকে কাতারে রেখে তাদের কাজ শেষ করে এবং গ্রাহকরা গ্রাহকরা আরম্ভ করার পরেই জানেন যে সারিটি খালি থাকলে তারা করা হবে they (এখানে উত্পাদক-ভোক্তার মধ্যে কোনও চুক্তি নেই তবে কেবল নির্মাতা-উত্পাদক এবং ভোক্তা-ভোক্তার মধ্যে)
unbounded blockingqueueএটি ব্যবহার করা হয় তবে এটি সিএএস ভিত্তিক ConcurrentLinkedQueue
আরেকটি সমাধান (এটি ভাল স্কেল করে না) হ'ল উপস্থাপনযোগ্য চ্যানেলগুলি: java.util.concurrent SyncronousQueue