জাভাতে বিঘ্নিত এক্সসেপশন পরিচালনা করা


317

হ্যান্ডলিংয়ের নিম্নলিখিত পদ্ধতিগুলির মধ্যে পার্থক্য কী InterruptedException? এটা করার সবচেয়ে ভালো উপায় কি?

try{
 //...
} catch(InterruptedException e) { 
   Thread.currentThread().interrupt(); 
}

অথবা

try{
 //...
} catch(InterruptedException e) {
   throw new RuntimeException(e);
}

সম্পাদনা: আমি আরও জানতে চাই যে এই দুটি ক্ষেত্রে কোনটি পরিস্থিতিতে ব্যবহৃত হয়।


উত্তর:


436

বিঘ্নিত এক্সসেপশন পরিচালনা করার নিম্নলিখিত পদ্ধতির মধ্যে পার্থক্য কী? এটা করার সবচেয়ে ভালো উপায় কি?

আপনি সম্ভবত এই প্রশ্নটি করতে এসেছেন কারণ আপনি এমন একটি পদ্ধতি বলেছেন যা ছুড়ে ফেলে InterruptedException

সবার আগে, আপনার এটি দেখতে throws InterruptedExceptionহবে: পদ্ধতির স্বাক্ষরের একটি অংশ এবং আপনি যে পদ্ধতিতে কল করছেন তার কল করার সম্ভাব্য ফলাফল। সুতরাং InterruptedExceptionএটিকে বাস্তবায়নের মাধ্যমে শুরু করুন যে পদ্ধতি পদ্ধতিতে একটি সঠিক বৈধ ফলাফল।

এখন, আপনি যে পদ্ধতিটিকে কল করছেন সেইরকম ব্যতিক্রম ছুঁড়ে ফেললে, আপনার পদ্ধতিটি কী করা উচিত ? আপনি নিম্নলিখিতটি সম্পর্কে চিন্তা করে উত্তরটি বের করতে পারেন:

এটা পদ্ধতির জন্য জানার আপনি একটি নিক্ষেপ করতে বাস্তবায়ন করছি InterruptedException? অন্যভাবে বলুন, আপনার পদ্ধতিটি InterruptedExceptionকল করার সময় কোনও বুদ্ধিমান ফলাফল কি?

  • যদি হ্যাঁ , তবে আপনার পদ্ধতির স্বাক্ষরের throws InterruptedExceptionঅংশ হওয়া উচিত এবং আপনার ব্যতিক্রমটি প্রচার করতে দেওয়া উচিত (অর্থাত্ এটি একেবারেই ধরবেন না)।

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

    int computeSum(Server server) throws InterruptedException {
        // Any InterruptedException thrown below is propagated
        int a = server.getValueA();
        int b = server.getValueB();
        return a + b;
    }
  • যদি না হয় , তবে আপনার সাথে আপনার পদ্ধতিটি ঘোষণা করা উচিত নয় throws InterruptedExceptionএবং আপনার অবশ্যই (অবশ্যই!) ব্যতিক্রমটি ধরা উচিত। এই পরিস্থিতিতে দুটি বিষয় অবশ্যই মনে রাখা গুরুত্বপূর্ণ:

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

    2. যদিও আপনার পদ্ধতিটি InterruptedExceptionথ্রেডটি বাধাগ্রস্ত হয়েছে এমন পরিস্থিতিতে ক্ষেত্রে একটি বুদ্ধিমান রিটার্ন মান উত্পাদন করতে পারে তা এখনও গুরুত্বপূর্ণ হতে পারে। বিশেষত, কোডটি যা আপনার পদ্ধতিটিকে কল করে তা আপনার পদ্ধতির কার্যকর করার সময় কোনও বাধা সৃষ্টি হয়েছে কিনা তা সম্পর্কে আগ্রহী হতে পারে। সুতরাং আপনার বাধিত পতাকাটি নির্ধারণ করে কোনও বাধা সৃষ্টি হয়েছিল তা লগ করা উচিত:Thread.currentThread().interrupt()

    উদাহরণ : ব্যবহারকারী দুটি মানের একটি যোগফল মুদ্রণ করতে বলেছে। মুদ্রণটি " Failed to compute sum" গ্রহণযোগ্য হয় যদি যোগফলটি গণনা করা যায় না (এবং কোনও কারণে স্ট্যাক ট্রেসের সাহায্যে প্রোগ্রামটি ক্র্যাশ হওয়ার চেয়ে অনেক ভাল InterruptedException)। অন্য কথায়, এটা নেই না দিয়ে এই পদ্ধতি ডিক্লেয়ার জানার জন্য throws InterruptedException

    void printSum(Server server) {
         try {
             int sum = computeSum(server);
             System.out.println("Sum: " + sum);
         } catch (InterruptedException e) {
             Thread.currentThread().interrupt();  // set interrupt flag
             System.out.println("Failed to compute sum");
         }
    }

এতক্ষণে এটি পরিষ্কার হওয়া উচিত যে কেবল করাটাই throw new RuntimeException(e)একটি খারাপ ধারণা। এটি কলারের কাছে খুব নম্র নয়। আপনি একটি নতুন রানটাইম ব্যতিক্রম উদ্ভাবন করতে পারেন তবে মূল কারণ (কেউ থ্রেড কার্যকর করা বন্ধ করতে চায়) হারিয়ে যেতে পারে।

অন্যান্য উদাহরণ:

বাস্তবায়নRunnable : আপনি যেমন আবিষ্কার করেছেন, এর স্বাক্ষর Runnable.runপুনর্বিবেচনার অনুমতি দেয় না InterruptedExceptions। ঠিক আছে, আপনি বাস্তবায়নে সাইন আপ করেছেন Runnableযার অর্থ আপনি সম্ভাব্যতার সাথে চুক্তি করতে সাইন আপ করেছেন InterruptedExceptions। হয় আলাদা ইন্টারফেস চয়ন করুন, যেমন Callable, বা উপরের দ্বিতীয় পদ্ধতির অনুসরণ করুন।

 

কলিংThread.sleep : আপনি কোনও ফাইল পড়ার চেষ্টা করছেন এবং অনুমান অনুসারে আপনার মধ্যে 1 সেকেন্ডের মধ্যে 10 বার চেষ্টা করা উচিত। আপনি কল Thread.sleep(1000)। সুতরাং, আপনি মোকাবেলা করা প্রয়োজন InterruptedException। কোনও পদ্ধতির জন্য tryToReadFileএটি সঠিকভাবে বোঝায় যে, "যদি আমার বাধা থাকে তবে আমি ফাইলটি পড়ার চেষ্টা করার আমার ক্রিয়াটি শেষ করতে পারি না" । অন্য কথায়, পদ্ধতিটি নিক্ষেপ করার জন্য এটি সঠিক ধারণা তৈরি করে InterruptedExceptions

String tryToReadFile(File f) throws InterruptedException {
    for (int i = 0; i < 10; i++) {
        if (f.exists())
            return readFile(f);
        Thread.sleep(1000);
    }
    return null;
}

এই পোস্টটি এখানে একটি নিবন্ধ হিসাবে আবার লেখা হয়েছে


দ্বিতীয় পদ্ধতিতে সমস্যা কী?
blitzkriegz

4
নিবন্ধটি বলেছে যে আপনার interrupt()বাধা দেওয়া স্থিতি রক্ষার জন্য কল করা উচিত । এটি না করার পিছনে কারণ কী Thread.sleep()?
oksayt

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

12
কলিং পদ্ধতিগুলি যা বিঘ্নিত ধারণাগুলি ছুঁড়ে ফেলে এবং বলে যে আপনি "বিঘ্নকে সমর্থন করেন না" slালু প্রোগ্রামিং এবং ত্রুটি হওয়ার জন্য অপেক্ষা করছে বলে মনে হচ্ছে। অন্যভাবে রাখুন; আপনি যদি এমন কোনও পদ্ধতিতে কল করেন যা বিঘ্নিত ধারণাটি ছুঁড়ে ফেলার ঘোষণা করা হয় তবে যদি সেই পদ্ধতিটি আসলে এই ধরনের ব্যতিক্রম ছুঁড়ে ফেলে তবে এটি একটি অপ্রত্যাশিত শর্ত নয়
আইয়ুব

1
@MartiNito, না, কলিং Thread.currentThread.interrupt()একটি ইন InterruptedExceptionধরা ব্লক শুধুমাত্র বিঘ্ন পতাকা সেট হবে। এটি অন্যকে InterruptedExceptionবহিরাগত InterruptedExceptionক্যাচ ব্লকে ফেলে / ধরা দেবে না ।
আইয়ুব

97

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

  1. প্রচার করুনInterruptedException - চেক নিক্ষেপ করার জন্য আপনার পদ্ধতিটি InterruptedExceptionএমনভাবে ঘোষণা করুন যাতে আপনার কলারের সাথে এটি মোকাবেলা করতে হয়।

  2. বাধা পুনরুদ্ধার করুন - কখনও কখনও আপনি নিক্ষেপ করতে পারবেন না InterruptedException। এই ক্ষেত্রে আপনার পদ্ধতিটি InterruptedExceptionকল করে বাধা স্ট্যাটাসটি পুনরুদ্ধার করা উচিত যাতে কোড উচ্চতর কল স্ট্যাক দেখতে পারে যে একটি বাধা দেওয়া হয়েছে, এবং দ্রুত পদ্ধতি থেকে ফিরে। দ্রষ্টব্য: এটি কেবল তখনই প্রযোজ্য যখন আপনার পদ্ধতিতে "চেষ্টা" বা "সেরা চেষ্টা" শব্দার্থবিজ্ঞান রয়েছে, অর্থাত্ যদি পদ্ধতিটি লক্ষ্য অর্জন না করে তবে সমালোচনামূলক কিছু ঘটবে না। উদাহরণস্বরূপ, বা এই জাতীয় পদ্ধতি হতে পারে, বা , কিন্তু না দেখুন এখানে আরো বিস্তারিত জানার জন্য।interrupt()currentThreadlog()sendMetric()boolean tryTransferMoney()void transferMoney()

  3. পদ্ধতির মধ্যে বাধা উপেক্ষা করুন, কিন্তু প্রস্থান করার পরে স্থিতি পুনরুদ্ধার করুন - যেমন পেয়ারা মাধ্যমে UninterruptiblesUninterruptiblesJCIP Non 7.1.3 এ ননক্যান্সেবল টাস্ক উদাহরণের মতো বয়লারপ্লেট কোডটি ধরুন।

10
"কখনও কখনও আপনি বাধাপ্রাপ্তি ছুঁড়ে ফেলতে পারবেন না" - আমি বলব, কখনও কখনও পদ্ধতিটির পক্ষে বাধা-বিপত্তি প্রচার করা উপযুক্ত নয় । আপনার সূত্রটি মনে হয় যে আপনি যখনই পারেন তখন বাধা-বিপত্তিটি পুনর্বার করা উচিত ।
আইওউব

1
এবং যদি আপনি অধ্যায় 7 পড়ার পেয়েছি, তুমি সেখানে তালিকা 7.7, ঐ যেখানে একটি noncancelable কাজের বিঘ্ন পুনঃস্থাপন করে না, এই কিছু সুক্ষ্ণ বিষয়গুলো আছে দেখতে পাবেন সরাসরি , কিন্তু পরে এটি সম্পন্ন হচ্ছে। এছাড়াও গীটজের সেই বইটির অনেক সহ-লেখক রয়েছে ...
Fizz

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

@ ইয়ানভো আমি আপনার পরামর্শটি প্রয়োগ করতে উত্তরটি সম্পাদনা করেছি।
লেভেন্টভ

18

আপনি কি করতে চেষ্টা করছেন?

InterruptedExceptionনিক্ষিপ্ত হয় যখন একটি থ্রেড অপেক্ষা বা ঘুমের এবং অন্য থ্রেড বিঘ্নিত এটি ব্যবহার করা হয় interruptক্লাসে পদ্ধতি Thread। সুতরাং আপনি যদি এই ব্যতিক্রমটি ধরেন তবে এর অর্থ হ'ল থ্রেডটি বাধা পেয়েছে। সাধারণত Thread.currentThread().interrupt();আবার ফোন করার কোনও মানে হয় না, যদি না আপনি অন্য কোথাও থ্রেডের "বাধা" স্থিতি পরীক্ষা করতে চান।

আপনার নিক্ষেপের অন্য বিকল্পটি সম্পর্কে RuntimeException, এটি করা খুব জ্ঞানী কাজ বলে মনে হচ্ছে না (এটি কে ধরবে? এটি কীভাবে পরিচালিত হবে?) তবে অতিরিক্ত তথ্য ছাড়া আরও বলা মুশকিল।


14
কলিং Thread.currentThread().interrupt()বিঘ্নিত পতাকাটিকে (আবার) সেট করে, যা সত্যই কার্যকর যদি আমরা তা নিশ্চিত করতে চাই যে বাধাটি একটি উচ্চ স্তরে লক্ষ করা যায় এবং প্রক্রিয়াজাত হয়।
প্যাটার টার্ক

1
@ পিটার: আমি এটি উল্লেখ করার জন্য উত্তরটি আপডেট করছি। ধন্যবাদ।
গ্রোড্রিগেজ

12

আমার কাছে এটির মূল বিষয়টি হ'ল: একটি বাধাগ্রস্ত হওয়া ধারণাটি কোনও ভুল হওয়ার নয়, এটি থ্রেড যা আপনি এটি করতে বলেছেন doing সুতরাং এটি একটি রানটাইম এক্সেক্সপটে মোড়ানো পুনর্বিবেচনা শূন্য করে তোলে।

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

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

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

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


10

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

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

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

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

আপনি যদি জানেন যে যৌক্তিক সাফাই করতে হবে, তবে এটি করুন। যদি আপনি বাধা দেওয়ার আরও গভীর কারণ জানেন তবে আপনি আরও বিস্তৃত পরিচালনা করতে পারেন।

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

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

3

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

  • ইন্টারপ্রেট এক্সসেপশন প্রচার করা

  • থ্রেডে বিঘ্নিত অবস্থা পুনরুদ্ধার করুন

বা অতিরিক্তভাবে:

  • বিঘ্নিত কাস্টম পরিচালনা

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

আমি বিষয়টি বোঝার জন্য অত্যন্ত পরামর্শ দিচ্ছি, তবে এই নিবন্ধটি তথ্যের একটি ভাল উত্স: http://www.ibm.com/developerworks/java/library/j-jtp05236/


0

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

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

সম্পাদনা: কমপক্ষে ওরাকলের টিউটোরিয়ালের উপর ভিত্তি করে অন্য একটি মামলা রক্ষা করা ব্লক হতে পারে: http://docs.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html


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

তাই আমি মাঝে মাঝে বলেছি। এছাড়াও এটি এখনও প্রস্তাবিত হয়নি এবং আমার মতে এটি কিছু ক্ষেত্রে পুরোপুরি ঠিক আছে । আমি অনুমান করি এটি নির্ভর করে আপনি কী ধরণের সফ্টওয়্যার তৈরি করছেন, তবে আপনার যদি 24/7 কর্মী থ্রেড থাকে যা কখনই বন্ধ না হওয়া উচিত (জেভিএম বন্ধ করা বাদে), আমি উদাহরণস্বরূপ একটি ব্লকিংকিউ থেকে কোনও আইটেম গ্রহণকে ত্রুটি হিসাবে বিবেচনা করব would (যেমন লগ) যেহেতু "এটি হওয়া উচিত নয়" এবং আবার চেষ্টা করুন। উত্স থেকে প্রোগ্রামের সমাপ্তি যাচাই করার জন্য আমার পৃথক পতাকা থাকবে। আমার কয়েকটি প্রোগ্রামে জেভিএম বন্ধ হয়ে যাওয়া এমন কিছু নয় যা সাধারণ ক্রিয়াকলাপের মধ্যে ঘটে।
বজর্ন বোস্ট্রিম

বা অন্য কোনও উপায়ে রাখুন: আমার মতে অতিরিক্ত বা ত্রুটিযুক্ত লগ স্টেটমেন্ট (এবং উদাহরণস্বরূপ ত্রুটির লগগুলিতে মেল পাঠানো) ঝুঁকি নেওয়া ভাল যা কোনও অ্যাপ্লিকেশন যা একটি বাধা বিপদের কারণে থামাতে 24/7 চালানো উচিত, যার জন্য আমি স্বাভাবিক অবস্থার সময় হওয়ার কোনও উপায় দেখি না।
বজর্ন বোস্ট্রামম

এইচ এম, ভাল, আপনার ব্যবহারের কেসগুলি পৃথক হতে পারে, তবে একটি আদর্শ বিশ্বে আপনি বাধা পেয়েছিলেন বলে আপনি কেবল শেষ করবেন না। আপনি কাতারে কাজ বন্ধ করে দিন এবং এই থ্রেডটি মারা যেতে দিন। যদি থ্রেডের শিডিয়ুলারটিও বাধাগ্রস্ত হয় এবং শাটডাউন করতে বলা হয়, তবে জেভিএম সমাপ্ত হচ্ছে, এবং এর খেলা শেষ হবে। বিশেষত, আপনি যদি কিল -9 প্রেরণ করেন বা অন্যথায় আপনার মেল সার্ভার বা যে কোনও কিছুই নেওয়ার চেষ্টা করছেন, তবে আপনাকে ছাড়তে বাধ্য না করা পর্যন্ত এটি আপনাকে অগ্রাহ্য করবে, এইভাবে আপনার কোডের অন্যান্য অংশগুলি প্রশংসনীয় শাটডাউন থেকে রোধ করবে। ডিস্ক বা ডিবিতে লেখার সময় জোর করে হত্যা করুন এবং আমি নিশ্চিত যে দুর্দান্ত জিনিসগুলি ঘটবে।
আজাক্স
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.