WatchServiceの Java トレイルには、次のように記載されています。
この API は、ハード ドライブのインデックス作成用には設計されていません。ほとんどのファイル システムの実装では、ファイル変更通知がネイティブでサポートされています。Watch Service API は、利用可能な場合、このサポートを利用します。ただし、ファイル システムがこのメカニズムをサポートしていない場合、監視サービスはファイル システムをポーリングし、イベントを待機します。
私の質問 ：
監視されているディレクトリがルート ディレクトリ (一部のサブディレクトリ) ではなく、ファイル システムが I/O イベント通知をサポートしていない場合、実装WatchServiceがファイル システムをポーリングしています。
または、言い換えれば、変更を検出するためにサービスがポーリングを実行する必要があるファイル システムを考慮して、この手法を使用するとシステム パフォーマンス (開始) の観点から問題になるしきい値 (ディレクトリの深さ、ファイルの量など) はありますか? OS のパフォーマンスに大きな影響を与える) ?
注: 頻繁に変化するディレクトリを監視すると、ファイル システムのポーリングに関係なく、イベントに応答するアプリケーションのビジー状態に影響し、さらに多くの CPU が必要になることを理解しています。システムデータフォルダー (つまり、ユーザーのドキュメントディレクトリなど) を監視することに関心があります。