الخلفية الفنية لمجموعة الخيوط
في البرمجة الموجهة للكائنات ، فإن إنشاء وتدمير الكائنات يستغرق وقتًا طويلاً ، لأن إنشاء كائن يتطلب موارد الذاكرة أو موارد أخرى أخرى. هذا أكثر من ذلك في Java ، حيث سيحاول الجهاز الظاهري تتبع كل كائن بحيث يمكن جمع القمامة بعد تدمير الكائن.
لذلك ، تتمثل إحدى الطرق لتحسين كفاءة برامج الخدمة في تقليل عدد مرات إنشاء وتدمير الأشياء ، وخاصة بعض الأشياء التي تستهلك الموارد وتدميرها. كيفية استخدام الكائنات الحالية للخدمة هي مشكلة رئيسية يجب حلها. في الواقع ، هذا هو السبب في إنتاج بعض تقنيات "تجميع الموارد".
على سبيل المثال ، لا تنفصل عن العديد من المكونات الشائعة التي تظهر عادة في Android عن مفهوم "البركة" ، مثل مكتبات تحميل الصور المختلفة ومكتبات طلبات الشبكة. حتى إذا كان Meaasge في آلية المراسلة في Android يستخدم meaasge.obtain () ، فهو الكائن في تجمع meaasge المستخدم ، لذلك هذا المفهوم مهم للغاية. تتوافق تقنية تجميع الخيوط المقدمة في هذه المقالة أيضًا مع هذه الفكرة.
مزايا تجمع الخيوط:
1. إعادة استخدام الخيوط في تجمع الخيوط لتقليل النفقات العامة للأداء الناجم عن إنشاء الكائنات وتدميرها ؛
2. يمكن أن تتحكم بشكل فعال في الحد الأقصى لعدد التزامن من مؤشرات الترابط ، وتحسين استخدام موارد النظام ، وتجنب المنافسة المفرطة للموارد وتجنب الانسداد ؛
3. القدرة على أداء إدارة بسيطة لخيوط متعددة ، مما يجعل استخدام المواضيع بسيطة وفعالة.
إطار عمل تجمع الخيوط المنفذ
يتم تنفيذ مجموعة الخيوط في Java من خلال إطار المنفذ. يتضمن إطار العمل المنفذ فصولًا: Executor ، Executors ، ExecutorService ، Threadpoolexecutor ، قابل للاستدعاء والمستقبل ، استخدام مستقبلات مستقبل ، إلخ.
المنفذ: هناك طريقة واحدة فقط لجميع واجهات تجمع الخيوط.
الواجهة العامة executor {void execute (runnable command) ؛ }ExecutorService: إضافة سلوك المنفذ هو الواجهة الأكثر مباشرة لفئة تنفيذ المنفذ.
المنفذون: يوفر سلسلة من أساليب المصنع لإنشاء تجمع مؤشرات الترابط ، وتنفيذ جميع تجمعات الخيوط التي تم إرجاعها واجهة ExecutorService.
Threadpoolexecutor: فئة التنفيذ المحددة لمجمعات الخيوط. يتم تنفيذ تجمعات الخيوط المختلفة المستخدمة بشكل عام بناءً على هذه الفئة. طريقة البناء كما يلي:
threadpoolexecutor العامة (int corepoolsize ، int maximumpoolsize ، keepalivetime الطويل ، الوحدة الزمنية ، blockingqueue <runnable> workqueue) {this (corepoolsize ، Maximumpoolsize ، keepalivetimCorePoolSize: لن يتجاوز عدد مؤشرات الترابط الأساسية في تجمع الخيوط ، وعدد مؤشرات الترابط التي تعمل في تجمع الخيوط أبدًا CorePoolsize ، ويمكن أن يبقى على قيد الحياة افتراضيًا. يمكنك تعيين ALTERCORETHREADTITEOT إلى TRUE ، وعدد المواضيع الأساسية هو 0 ، والتحكم في الوقت الذي يتحكم فيه في وقت المهلة لجميع المواضيع.
MaximumpoolSize: الحد الأقصى لعدد الخيوط المسموح بها من قبل تجمع الخيوط ؛
Keepalivetime: يشير إلى وقت المهلة عندما ينتهي مؤشر ترابط الخمول ؛
الوحدة: هو التعداد ، يمثل وحدة keepalivetime ؛
WorkQueue: يمثل plockingqueue <queue raundable الذي يخزن المهمة.
Plockingqueue: Blockingqueue هو أداة تستخدم بشكل أساسي للتحكم في مزامنة مؤشر الترابط تحت java.util.concurrent. إذا كان blockqueue فارغًا ، فسيتم حظر تشغيل شيء ما من blockingqueue ولن يتم إيقاظه حتى يدخل blockingqueue إلى الشيء. وبالمثل ، إذا كانت blockingqueue ممتلئة ، فسيتم حظر أي عملية تخزين الأشياء فيه ولن يتم إيقاظها لمواصلة العمليات حتى يكون هناك مساحة في blockingqueue. غالبًا ما يتم استخدام قوائم الانتظار في سيناريوهات المنتجين والمستهلكين. المنتجون هم مؤشرات ترابط يضيفون عناصر إلى قوائم الانتظار ، والمستهلكين هم مؤشرات ترابط يأخذ عناصر من قوائم الانتظار. قائمة انتظار الحظر هي الحاوية التي يخزن فيها المنتج عناصر ، ويأخذ المستهلك فقط عناصر من الحاوية. تشمل فئات التنفيذ المحددة LinkedBlockingQueue ، ArrayBlockingqueued ، وما إلى ذلك بشكل عام ، يتم تحقيق الحظر الداخلي والاستيقاظ من خلال القفل والشرط (تعلم واستخدام أقفال العرض والظروف).
عملية عمل تجمع الخيوط هي كما يلي:
عندما تم إنشاء تجمع الخيوط لأول مرة ، لم يكن هناك موضوع في الداخل. يتم تمرير قائمة انتظار المهمة كمعلمة. ومع ذلك ، حتى لو كانت هناك مهام في قائمة الانتظار ، فلن يقوم تجمع الخيوط بتنفيذها على الفور.
عند إضافة مهمة عن طريق استدعاء طريقة Execute () ، فإن مجموعة مؤشرات الترابط ستصدر الحكم التالي:
إذا كان عدد مؤشرات الترابط تشغيل أقل من CorePoolsize ، فقم بإنشاء مؤشر ترابط لتشغيل هذه المهمة على الفور ؛
إذا كان عدد مؤشرات الترابط الجارية أكبر من أو يساوي CorePoolsize ، فضع هذه المهمة في قائمة الانتظار ؛
إذا كانت قائمة الانتظار ممتلئة في هذا الوقت وكان عدد مؤشرات الترابط الجارية أقل من حجم Maximumpoolsize ، فلا تزال بحاجة إلى إنشاء مؤشر ترابط غير نواة لتشغيل المهمة على الفور ؛
إذا كانت قائمة الانتظار ممتلئة وكان عدد مؤشرات الترابط الجارية أكبر من أو يساوي MaximumpoolSize ، فسيقوم تجمع مؤشرات الترابط بإلقاء استثناء رفض.
عندما يكمل مؤشر ترابط المهمة ، يستغرق المهمة التالية من قائمة الانتظار لتنفيذها.
عندما لا يكون لخيط ما يفعله ، وبعد فترة زمنية معينة (Keepalivetime) ، سيحكم تجمع الخيوط على أنه إذا كان عدد المواضيع التي تعمل حاليًا أكبر من CorePoolsize ، فسيتم إيقاف الخيط. لذلك بعد اكتمال جميع مهام تجمع الخيوط ، سيتم تقليصها في النهاية إلى حجم CorePoolsize.
إنشاء واستخدام تجمعات الخيوط
يستخدم تجمع مؤشرات ترابط الجيل الطريقة الثابتة لمنفذي فئة الأدوات. فيما يلي العديد من تجمعات الخيوط الشائعة.
SingleThreadExecutor: موضوع خلفية مفردة (قائمة انتظار المخزن المؤقت غير محدودة)
static static statorservice newsinglethreadexecutor () {return new FinizabledElegatedExecutorservice (New Threadpoolexecutor (1 ، 1 ، 0L ، timeUnit.millisEconds ، New LinkedBlockingqueue <Runnable> ())) ؛ }إنشاء تجمع مؤشر ترابط واحد. يحتوي تجمع الخيوط هذا على مؤشر ترابط أساسي واحد فقط ، وهو ما يعادل مؤشر ترابط واحد يقوم بجميع المهام في المسلسل. إذا انتهى هذا الخيط الفريد بسبب الاستثناء ، فسيكون هناك مؤشر ترابط جديد لاستبداله. يضمن تجمع مؤشرات الترابط هذا تنفيذ ترتيب تنفيذ جميع المهام بترتيب تقديم المهمة.
FlexThreadPool: فقط مجموعة مؤشرات الترابط من مؤشرات الترابط الأساسية ، مع حجم ثابت (قائمة انتظار المخزن المؤقت غير محدودة).
static static evecororservice newfixedThreadPool (int nthreads) {
إرجاع Threadpoolexecutor الجديد (nThreads ، nthreads ،
0L ، timeunit.milliseconds ،
New LinkedBlockingQueue <Runnable> ()) ؛
}
قم بإنشاء تجمع خيوط ثابت الحجم. في كل مرة يتم فيها تقديم مهمة ، يتم إنشاء مؤشر ترابط حتى يصل مؤشر الترابط إلى الحد الأقصى لحجم تجمع الخيوط. يبقى حجم تجمع الخيوط كما هو بمجرد وصوله إلى أقصى قيمته. إذا انتهى مؤشر ترابط بسبب استثناء التنفيذ ، فسيضيف تجمع مؤشرات الترابط مؤشر ترابط جديد.
CachedThreadPool: تجمع الخيوط غير المحدود ، يمكنه إجراء إعادة تدوير مؤشرات الترابط التلقائي.
static static eventorservice newCachedThreadPool () {return new threadpoolexecutor (0 ، integer.max_value ، 60l ، timeUnit.seconds ، synchronousqueue <runnable> ()) ؛ }إذا تجاوز حجم تجمع مؤشرات الترابط الخيط المطلوب لمعالجة المهمة ، فسيتم إعادة تدوير بعض مؤشرات الترابط الخاملة (بدون تنفيذ المهمة في 60 ثانية). عندما يزداد عدد المهام ، يمكن لتجمع مؤشرات الترابط هذا إضافة مؤشرات ترابط جديدة بذكاء لمعالجة المهمة. لا يحد تجمع مؤشرات الترابط هذا من حجم تجمع مؤشرات الترابط ، والذي يعتمد كليا على الحد الأقصى لحجم مؤشر الترابط الذي يمكن أن ينشئه نظام التشغيل (أو JVM). Synchronousqueue هو قائمة انتظار الحظر مع المخزن المؤقت من 1.
SecrledThreadPool: تجمع مؤشرات ترابط أساسي مع تجمع مؤشر ترابط أساسي ثابت وحجم غير محدود. يدعم تجمع الخيوط هذا الحاجة إلى أداء المهام بشكل دوري وفوري.
static static evecororservice newscheduledthreadpool (int corepoolsize) {return new SecrettHreadPool (corepoolsize ، integer.max_value ، default_keepalive_millis ، milliseconds ، new Workedqueue ()) ؛ }قم بإنشاء تجمع مؤشر ترابط يؤدي المهام بشكل دوري. إذا كان الخمول ، فسيتم إعادة تدوير تجمع الخيوط غير النواة في وقت Default_keepalivemillis.
هناك طريقتان أكثر شيوعًا لتقديم المهام في تجمعات الخيوط:
ينفذ:
ExecutorService.execute (Runnable Runable) ؛
يُقدِّم:
مهمة FutureTask = ExecutorService.submit (Runnable Runnable) ؛
FutureTask <T> Task = ExecutorService.Submit (Runnable Runnable ، T Results) ؛
FutureTask <T> Task = ExecutorService.submit (قابل للاتصال <T> قابل للاتصال) ؛
وينطبق الشيء نفسه على تنفيذ إرسال (قابل للاتصال قابل للاتصال) ونفس الشيء ينطبق على إرسال (Runnable Runnable).
Public <T> Future <T> إرسال (المهمة القابلة للاتصال <T>) {if (task == null) رمي nullpointerxception () ؛ FutureTask <T> ftask = newTaskfor (Task) ؛ تنفيذ (ftask) ؛ إرجاع ftask ؛}يمكن ملاحظة أن الإرسال هي مهمة تُرجع نتيجة ، وسوف تُرجع كائن مستقبلي ، بحيث يمكن الحصول على النتيجة من خلال طريقة GET (). المكالمة النهائية للإرسال هي أيضًا تنفيذ (Runnable Runable). يقدم إرسال الكائن القابل للاتصال فقط أو يمكن تشغيله في كائن مستقبلي. نظرًا لأن FutureTask يمكن تشغيله ، يمكن تنفيذها في التنفيذ. لمعرفة كيف يتم تغليف الكائنات القابلة للاتصال و rawnable في كائنات مستقبلية ، انظر استخدام قابلة للاتصال ، مستقبل ، مستقبلات.
مبدأ تنفيذ تجمع الخيوط
إذا تحدثت فقط عن استخدام حمامات التجمعات ، فإن هذه المدونة ليس لها قيمة كبيرة. في أحسن الأحوال ، إنها مجرد عملية للتعرف على واجهة برمجة التطبيقات المتعلقة بالمنفذ. لا تستخدم عملية تنفيذ تجمع مؤشرات الترابط الكلمة الرئيسية المتزامنة ، ولكنها تستخدم قوائم قوائم قوائم متطايرة وقفل ومتزامنة (حظر) ، فئات ذرية ذات صلة ، مستقبلات مستقبلية ، إلخ ، لأن الأخير له أداء أفضل. يمكن لعملية التفاهم أن تتعلم فكرة التحكم المتزامن في الكود المصدر جيدًا.
يتم تلخيص مزايا تجميع الخيوط المذكورة في البداية على النحو التالي:
إعادة استخدام الموضوع
تحكم في الحد الأقصى لعدد التوافق
إدارة المواضيع
1. عملية الإرسال الضاعف
لفهم مبدأ تعدد الخيط ، يجب عليك أولاً فهم دورة حياة الخيط.
خلال دورة حياة الخيط ، يجب أن يمر عبر خمس ولايات: جديدة ، قابلة للتشغيل ، الجري ، المحظورة والموت.
الخيط يخلق موضوع جديد من خلال جديد. هذه العملية هي تهيئة بعض معلومات مؤشر الترابط ، مثل اسم مؤشر الترابط ، والمعرف ، والمجموعة التي ينتمي إليها مؤشر الترابط ، وما إلى ذلك ، والتي يمكن اعتبارها مجرد كائن عادي. بعد استدعاء Thread's Start () ، يقوم Java Virtual Machine بإنشاء مكدس استدعاء وأجهزة تشغيل للبرنامج لذلك ، وفي الوقت نفسه ، تم Hasbeenstart إلى True ، ثم سيكون هناك استثناء عند استدعاء طريقة البدء.
لا يبدأ الخيط في هذه الحالة في التشغيل ، ولكن يعني فقط أن الخيط يمكن تشغيله. أما عندما يبدأ الخيط في التشغيل ، فإنه يعتمد على الجدولة في JVM. عندما يحصل مؤشر الترابط على وحدة المعالجة المركزية ، سيتم استدعاء طريقة Run (). لا تدعو Thread's Run () طريقة بنفسك. بعد ذلك ، قم بالتبديل بين الحظر الجاهز وفقًا لجدولة وحدة المعالجة المركزية ، حتى تنتهي طريقة Run () أو إيقاف طرق أخرى من الخيط وأدخل الحالة الميتة.
لذلك ، يجب أن يكون مبدأ تنفيذ إعادة استخدام مؤشر الترابط هو الحفاظ على الخيط على قيد الحياة (جاهز أو تشغيل أو حظر). بعد ذلك ، دعونا نلقي نظرة على كيفية تنفيذ ThreadPoolexecutor.
فئة العمال الرئيسية في Threadpoolexecutor Controls إعادة استخدام مؤشر الترابط. ألقِ نظرة على الكود المبسط لفئة العمال ، لذلك من السهل فهمه:
يقوم عامل الفئة النهائي الخاص بتنفيذ Runnable {Final Thread Thread ؛ Runnable FirstTask ؛ عامل (RunNable firstTask) {this.firsttask = firstTask ؛ this.thread = getThreadFactory (). w.firsttask ؛ w.firsttask = null ؛ بينما (المهمة! = null || (task = getTask ())! = null) {task.run () ؛}}العامل قابل للتشغيل وله موضوع في نفس الوقت. هذا الموضوع هو الخيط المراد فتحه. عند إنشاء كائن عامل جديد ، يتم إنشاء كائن مؤشر ترابط جديد في نفس الوقت ، ويتم تمرير العامل نفسه إلى tthread كمعلمة. وبهذه الطريقة ، عندما يتم استدعاء طريقة START () للمعلومات ، يتم تشغيل طريقة Run () للعامل بالفعل. ثم في Runworker () ، هناك حلقة من الوقت ، والتي تستمر في الحصول على الكائن القابل للتشغيل من getTask () وتنفيذها بالتسلسل. كيف يحصل getTask () على الكائن القابل للتشغيل؟
لا يزال الرمز المبسط:
private runnable getTask () {if (بعض الحالات الخاصة) {return null ؛ } runnable r = workqueue.take () ؛ return r ؛}هذا العمل هو قائمة انتظار Plockingqueue التي تخزن المهام عند تهيئة ThreadPoolexecutor. قائمة الانتظار تخزن المهام القابلة للتشغيل. نظرًا لأن blockingqueue عبارة عن قائمة انتظار حظر ، فإن blockingqueue.take () يصبح فارغًا ، ويدخل حالة الانتظار حتى تتم إضافة كائن جديد في blockingqueue لإيقاظ الخيط المحظور. لذلك ، بشكل عام ، لن تنتهي طريقة Run () من مؤشر الترابط ، ولكنها ستستمر في تنفيذ المهام القابلة للتشغيل من WorkQueue ، والتي تحقق مبدأ إعادة استخدام مؤشر الترابط.
2. التحكم في الحد الأقصى لعدد التوافق
إذن متى يتم وضع Runnable في Workqueue؟ متى يتم إنشاء العامل؟ متى يتم تسمى الخيط في العامل START () لفتح مؤشر ترابط جديد لتنفيذ طريقة تشغيل العامل ()؟ يوضح التحليل أعلاه أن Runworker () في العامل يؤدي المهام واحدة تلو الأخرى ، بشكل متسلسل ، فكيف يظهر التزامن نفسه؟
من السهل التفكير في أنك ستقوم ببعض المهام المذكورة أعلاه عند التنفيذ (Runnable Runnable). دعونا نرى كيف يتم ذلك في التنفيذ.
ينفذ:
رمز مبسط
تنفيذ public void (الأمر runnable) {if (command == null) رمي nullpointerxception () إذا كان (Addworker (command ، true)) return ؛ c = ctl.get () ؛} // عدد مؤشرات الترابط النشطة> = corepoolsize // runState قيد التشغيل && قائمة انتظار غير ممتلئة إذا (c) (! isrunning (إعادة التحقق) && إزالة (أمر)) رفض (command) ؛ // استخدم الإستراتيجية المحددة بواسطة مجموعة مؤشرات الترابط لرفض المهمة // حالتين: //Addworker:
رمز مبسط
Private Boolean Addworker (Runnable FirstTask ، Boolean Core) {int wc = workercountof (c) ؛ if (wc> = (core؟ corepoolsize: maximumpoolsize)) {return false ؛} w = new Homeer (firsttask) ؛ thread t = wthread ؛ t.start () ؛} ؛}وفقًا للرمز ، دعونا نلقي نظرة على الموقف المذكور أعلاه لإضافة المهام أثناء عمل تجمع الخيوط:
* إذا كان عدد مؤشرات الترابط الجارية أقل من CorePoolsize ، فقم بإنشاء مؤشر ترابط لتشغيل هذه المهمة على الفور ؛
* إذا كان عدد مؤشرات الترابط تشغيل أكبر من أو يساوي CorePoolsize ، فضع هذه المهمة في قائمة الانتظار ؛
* إذا كانت قائمة الانتظار ممتلئة في هذا الوقت وكان عدد مؤشرات الترابط الجارية أقل من MaximumpoolSize ، فلا يزال عليك إنشاء مؤشر ترابط غير النواة لتشغيل المهمة على الفور ؛
* إذا كانت قائمة الانتظار ممتلئة وكان عدد مؤشرات الترابط الجارية أكبر من أو يساوي MaximumpoolSize ، فسيقوم تجمع مؤشرات الترابط بإلقاء استثناء رفض.
هذا هو السبب في تنفيذ Asynctask من Android بالتوازي ويتجاوز الحد الأقصى لعدد المهام والرميات الرفض. للحصول على تفاصيل ، يرجى الرجوع إلى أحدث إصدار من تفسير رمز المصدر Asynctask والجانب المظلم من Asynctask
إذا تم إنشاء مؤشر ترابط جديد بنجاح من خلال Addworker ، فستبدأ () واستخدم FirstTask كمهمة أول تنفيذ في Run () في هذا العامل.
على الرغم من أن مهمة كل عامل هي المعالجة التسلسلية ، إذا تم إنشاء العديد من العمال ، لأنهم يشتركون في عمل ، سيتم معالجتهما بالتوازي.
لذلك ، يتم التحكم في الحد الأقصى لرقم التزامن وفقًا لـ CorePoolsize و MaximumpoolSize. يمكن تمثيل العملية العامة بالرقم أدناه.
التفسير والصور أعلاه يمكن فهمه جيدًا.
إذا كنت منخرطًا في تطوير Android وكنت على دراية بمبادئ المعالج ، فقد تعتقد أن هذه الصورة مألوفة للغاية. بعض العمليات تشبه إلى حد كبير تلك التي تستخدمها المعالج ، Looper ، و Meaasge. معالج. قائمة انتظار meaasge المحفوظة في Looper تعادل Plockingqueue. ومع ذلك ، تحتاج إلى الحفاظ على قائمة الانتظار هذه عن طريق التزامن. وظيفة الحلقة () في حلقات looper لأخذ meaasge من قائمة انتظار meaasge و Runwork () في العامل يمكن تشغيلها باستمرار من blockingqueue.
3. إدارة المواضيع
من خلال تجمع الخيوط ، يمكننا إدارة إعادة استخدام مؤشرات الترابط ، والتحكم في رقم التزامن ، وتدمير العمليات. تمت مناقشة إعادة استخدام مؤشر الترابط وتزامن التحكم أعلاه ، وتخللت عملية إدارة الخيوط فيه ، وهو أمر سهل الفهم.
هناك متغير CTL AtomicInteger في ThreadPoolexecutor. يتم حفظ محتلين من خلال هذا المتغير:
عدد جميع المواضيع. كل مؤشر ترابط في حالة يتم فيها تخزين 29 بت من الخيوط وتخزين 3 بتات أعلى من State. يتم الحصول على قيم مختلفة من خلال عمليات بت.
خاص خاص AtomicInteger CTL = New AtomicInteger (Ctlof (Running ، 0)) ؛ // احصل على حالة int state int stateof (int c) {return c & ~ capital ؛ السعة ؛} // المصطلح ما إذا كان الخيط يعمل بشكل خاص ثابت منطقي isrunning (int c) {return c <stapdown ؛}هنا ، يتم تحليل عملية إيقاف تجمع الخيوط بشكل أساسي عن طريق إيقاف التشغيل وإغلاق NOW (). بادئ ذي بدء ، يحتوي مجموعة مؤشرات الترابط على خمس ولايات للتحكم في إضافة المهمة وتنفيذها. يتم تقديم الأنواع الثلاثة الرئيسية التالية:
حالة التشغيل: يتم تشغيل تجمع مؤشرات الترابط بشكل طبيعي ، ويمكنه قبول مهام جديدة ومهام معالجة في قائمة الانتظار ؛
حالة الإغلاق: لا يتم قبول أي مهام جديدة ، ولكن سيتم تنفيذ المهام في قائمة الانتظار ؛
حالة الإيقاف: لم تعد هناك مهام جديدة مقبولة ، ولا تتم معالجة إيقاف المهمة في قائمة الانتظار. ستعمل هذه الطريقة على تعيين RunState على إيقاف التشغيل ، وستقوم بإنهاء جميع مؤشرات الترابط الخاملة ، في حين أن الخيوط التي لا تزال تعمل لا تتأثر ، لذلك سيتم تنفيذ شخص المهمة في قائمة الانتظار.
تعمل طريقة إيقاف التشغيل على إيقافها. الفرق بين طريقة الإغلاق ، ستنهي هذه الطريقة جميع مؤشرات الترابط ، لذلك لن يتم تنفيذ المهام في قائمة الانتظار.
ملخص: من خلال تحليل رمز مصدر ThreadPoolexecutor ، لدينا فهم عام لعملية إنشاء تجمعات مؤشرات الترابط ، وإضافة المهام ، وتنفيذ تجمعات الخيوط. إذا كنت معتادًا على هذه العمليات ، فسيكون من الأسهل استخدام تجمعات مؤشرات الترابط.
سيكون بعض التحكم في التزامن المستفاد منه واستخدام معالجة المهام لنماذج المنتجين والمستهلكين بمساعدة كبيرة لفهم أو حل المشكلات الأخرى ذات الصلة في المستقبل. على سبيل المثال ، فإن آلية المعالج في Android ، وقائمة انتظار Messager في Looper هي أيضًا على ما يرام لاستخدام blookqueue للتعامل معها. هذا هو كسب قراءة رمز المصدر.
ما سبق هو المعلومات التي تقوم بفرز تجمع خيوط Java. سنستمر في إضافة المعلومات ذات الصلة في المستقبل. شكرا لدعمكم لهذا الموقع!