worker ໜຶ່ງພົບ proxy ທີ່ໃຊ້ໄດ້. ທ່ານສົ່ງຄືນທີ່ຢູ່ຂອງມັນ, ເອີ້ນ cancel ໃສ່ future ອື່ນໆ, ແລະ ຄາດຫວັງວ່າການເຄື່ອນໄຫວຂອງເຄືອຂ່າຍຈະຢຸດ. ອາດຈະບໍ່ຢຸດ.

Future ສາມາດຖືກຍົກເລີກກ່ອນ callable ຂອງມັນເລີ່ມ. ເມື່ອ thread ກຳລັງປະຕິບັດຄຳຮ້ອງຂໍຢູ່ແລ້ວ, ການຍົກເລີກ Future ຂອງມັນບໍ່ໄດ້ຂັດຂວາງການດຳເນີນການ socket ນັ້ນ. worker ຕ້ອງການການດຳເນີນການເຄືອຂ່າຍທີ່ມີຂອບເຂດ ແລະ ເສັ້ນທາງທຳຄວາມສະອາດຂອງຕົນເອງ.

ອາຍຸການຂອງ executor ກໍສຳຄັນ. ການອອກຈາກບໍລິບົດ ThreadPoolExecutor ລໍຖ້າໃຫ້ວຽກຂອງມັນສຳເລັດ. ການພົບຜົນລັບໄວໜຶ່ງອັນ ແລ້ວລໍຖ້າ worker ທີ່ຊ້າຫຼາຍອັນ ອາດເຮັດໃຫ້ການລ່າຊ້າທັງໝົດຂອງຜູ້ເອີ້ນເບິ່ງບໍ່ຄືກັບ latency ທີ່ຜູ້ຊະນະລາຍງານເລີຍ.

ຈຳກັດການແຂ່ງຂັນກ່ອນເລີ່ມ

  • ຈຳກັດຈຳນວນການກວດສອບພ້ອມກັນ ແທນທີ່ຈະສົ່ງລາຍການສາທາລະນະທີ່ບໍ່ມີຂອບເຂດ. ລາຍການ proxy ຟຣີ ໃຫ້ຜູ້ສະໝັກສຳລັບການປ້ອນຂໍ້ມູນຂອງຜູ້ກວດສອບ, ໂດຍຮັກສາໂປຣໂຕຄອນຂອງແຕ່ລະຈຸດສຸດທ້າຍໄວ້ສຳລັບ worker.
  • ໃຫ້ແຕ່ລະຄຳຮ້ອງຂໍມີນະໂຍບາຍການເຊື່ອມຕໍ່ ແລະ ການອ່ານທີ່ເໝາະສົມ.
  • ໃຫ້ງົບປະມານການຕັດສິນໃຈລວມແກ່ຜູ້ເອີ້ນ.
  • ກຳນົດວ່າໃຜເປັນຜູ້ລະບາຍ ຫຼື ປິດຜົນຈາກ worker ທີ່ຢູ່ລອດຫຼັງການຕັດສິນໃຈ.

ການລໍຖ້າ Future ໜ້ອຍລົງ ບໍ່ຄືກັບການເຮັດໃຫ້ຄຳຮ້ອງຂໍພື້ນຖານຂອງມັນສັ້ນລົງ. ເຊັ່ນດຽວກັນ, ການປະຖິ້ມຜົນບໍ່ໄດ້ປ່ອຍຊັບພະຍາກອນເຄືອຂ່າຍທັງໝົດທັນທີ.

ຜົນສຳເລັດອັນທຳອິດກໍພຽງແຕ່ການກວດສອບສຳເລັດອັນທຳອິດເທົ່ານັ້ນ. ມັນອາດຂຶ້ນກັບການຈັດຕາຕະລາງ, ການເຊື່ອມຕໍ່ທີ່ເກັບໄວ້, ແລະ ປາຍທາງການກວດສອບສະເພາະ. ມັນບໍ່ໄດ້ພິສູດວ່າຈຸດສຸດທ້າຍໄວທີ່ສຸດໃນທົ່ວໂລກ ຫຼື ວ່າວຽກຈິງຈະສຳເລັດ.

ເລື້ອຍໆ ສະລອຍນ້ຳນ້ອຍໆທີ່ເກັບຮັກສາໄວ້ພ້ອມການສັງເກດລ່າສຸດ ແມ່ນງ່າຍກວ່າການແຂ່ງຂັນກັບລາຍການທັງໝົດກ່ອນການດາວໂຫຼດແຕ່ລະຄັ້ງ. ໃຊ້ຜົນຂອງການດຳເນີນການຈິງເພື່ອອັບເດດບັນທຶກ, ພ້ອມກັບ ນະໂຍບາຍການຟື້ນຕົວທີ່ຄວບຄຸມສຳລັບຄວາມຜິດພາດ. ການກວດສອບກ່ອນຄວນຫາລາຍໄດ້ພໍກັບຄ່າໃຊ້ຈ່າຍ ແທນທີ່ຈະເພີ່ມວຽກແຕ່ລະອັນເປັນສອງເທົ່າຕາມນິໄສ.

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ