100〜150台のデバイスを監視できる監視アプリケーションを作成しています...監視アプリケーションを設計するために、2つのアプローチがあります。-
監視するデバイスごとにスレッドを作成すると、各スレッドがデバイスにping（ICMPを使用）して、デバイスがオンラインかどうかを確認します。これらのスレッドは、特定の時間間隔（たとえば、60秒）後にステータスを知るために無期限に実行されます。
スレッドプールを作成し、デバイスごとに、タスクをスレッドプールに送信します。タスクは、デバイスへの単純なpingです。したがって、現在の設計では、タスクはスレッドプール内のスレッド以上のものになります。たとえば、監視するデバイスが100ある場合、監視するタスクは100あり、スレッドプールにはこれらの100のタスクを完了するためのスレッドが40あります。もちろん、次の一連のタスクを実行する時間は、スレッドプール内のすべての保留中のタスクを完了するようなものになります。
どちらのアプローチが良いでしょうか？
繰り返しのpingをスケジュールできるようにScheduledExecutorService（たとえば、経由で）作成します。Executors.newScheduledThreadPool各pingにかかる可能性のある時間を知っていますか？100台のデバイスのそれぞれに1分に1回だけpingを実行する必要がある場合は、スレッドが非常に少なく、40よりはるかに少ないスレッドで解決できることを願っています。
かなり少数のスレッドで開始できますが、コメントでMark Petersが提起した情報に注意してください。使用される実装は拡張されません（予想どおり）。それは事実上固定スレッドプールです。それでも、40未満でできるはずです...
デバイスごとに個別のスレッドを作成することは、スケーラブルなソリューションではありません。ソリューションが100から1000など、より多くのデバイスで機能する必要があるかどうかを想像してみてください。毎回別々にスポーンし続けることはできません。
スレッドプールを作成することは、望ましい解決策です。要件とリソースの可用性に応じて、スレッドプールのサイズを調整できます。一定の間隔を置いてデバイスに定期的にpingを実行する必要がある場合は、タスクのスケジュールを内部的に定期的に処理するスケジュールされたエグゼキュータサービスを利用できます。しかし、はい、スレッドプールを使用することは当然の選択です。
スレッドの最大数を計算するときは、pingタイムアウトを考慮する必要があります。pingタイムアウトが5秒、繰り返し期間が60秒の場合、100台のデバイスにpingを実行する必要があるスレッドはいくつですか。
60秒で、各スレッドは12個のデバイスpingを実行できます（60秒では、5秒後に12個のpingがタイムアウトします）。つまり、60秒ごとに12回のpingを実行するスレッドが少なくとも9つ必要です。
numberOfThreads = numberOfDevices /（pollingPeriod / pingTimeout）= 100 /（60/5）= 100/12=9スレッド
デバイスごとに新しいスレッドを作成するのではなく、スレッドプールを使用することをお勧めします。スレッドプールは、期間が短い多くのタスクに適しており、問題はこれに完全に適合します。