また、スレッドと比較して、継承に加えて、コードとデータの独立性は実行可能にどのように反映されますか?どこかのブログに書いてあったように、スレッドはリソースを共有できないが、runnableはリソースを共有できるので、スレッド内の変数をstaticに変更するだけで十分ではないでしょうか?次の記事のように http://blog.csdn.net/uudou/ar...
データとはあまり関係ないようですが、Runnable には次の 2 つの利点があると思います。
を使用します)。 executorService.exec(command),挫一点也可以用new Thread(command).start()),也可以不开线程阻塞式的跑(直接调用command.run()
executorService.exec(command)
new Thread(command).start()
command.run()
リーリー
Runnable的好处是各种场景都可以用,比如你可以让任何一个Class implements Runnable,但是extends ThreadJava の単一継承のため、いくつかの制限があります。
Runnable
Class implements Runnable
extends Thread
答え:
この問題は設計上の問題と考えられます。
ThreadとRunnableを分離する理由は、スレッドの「作成プロセス」とスレッドの「実行ロジック」を完全に分離するためです。
言い換えると: スレッド作成プロセスは「コード」です。スレッドの実行ロジックは「データ」です。
1. hello world という文を出力します。
注: 実行 1 とは何ですか? それとも2?パラメータnによって決定され、nは乱数です...
1. hello world を出力します。 2. int a と int b の合計を計算し、それを出力します。
現時点では、スレッドの作成プロセスを変更する必要があることに注意してください。つまり、開始関数を変更する必要があります。 リーリー この議論は終わりです。注意深く観察しましょう...実際: リーリー コードのこの部分は変更されず、必要に応じて開始関数のコードのみが変更されます。
それでは、変更されたコンテンツのこの部分をインターフェースにパッケージ化できますか? ?
これは良いアイデアになるはずです!
もう完全に理解できたかわかりませんが? :D
はは、Java の Thread クラスは、Runnable パラメーターを備えたコンストラクターを提供するだけではないでしょうか?
ビジネス コードを Runnable インターフェイスの実装クラスに追加します。
それで、最終的には次のように呼び出すことができます:
これでスレッドの「作成プロセス」と「ビジネスロジック」の完全分離が完了しました!この「分割」により、Java スレッド プール テクノロジへの道も開かれました。
正直に言うと、サンプルコードの Thread t = new Thread() { ... } は十分簡単ですが、スレッド プールに Thread を作成するのはそれほど簡単ではありません。
だから「分割」はとても必要なのです!
また、次のように想像できますか?
Runnable 実装クラスに Runnable リストが含まれている場合はどうなりますか?
概要:
1. Runnable インターフェイスを使用する目的は、スレッドの「作成プロセス」をスレッドの「実行ロジック」から完全に分離することです。2. スレッドはリソースを共有できますが、このステートメントは正しくありません。 ; 3. 議論の中で、私は具体的なものから抽象的なものへと移行しました。 さて、上記はこの質問に対する私の答えです。お役に立てば幸いです。
データとはあまり関係ないようですが、Runnable には次の 2 つの利点があると思います。
を使用します)。
Java 1.8 以降は Lambda で実行できます。例:executorService.exec(command)
,挫一点也可以用new Thread(command).start()
),也可以不开线程阻塞式的跑(直接调用command.run()
リーリー
Runnable
的好处是各种场景都可以用,比如你可以让任何一个Class implements Runnable
,但是extends Thread
Java の単一継承のため、いくつかの制限があります。答え:
この問題は設計上の問題と考えられます。
ThreadとRunnableを分離する理由は、スレッドの「作成プロセス」とスレッドの「実行ロジック」を完全に分離するためです。
言い換えると:
これは少しわかりにくいように思えますが、すべて JAVA コードではないでしょうか?コードが再びデータになるのはなぜですか?スレッド作成プロセスは「コード」です。
スレッドの実行ロジックは「データ」です。
1. hello world という文を出力します。
2. int a と int b の合計を計算して出力します。注: 実行 1 とは何ですか? それとも2?パラメータnによって決定され、nは乱数です...
これら 2 つのタスクを同じスレッドで実行するには、次のようなコードを書くことができます:リーリー
上記のコードは実際にタスクを完了できますが、問題はスレッドの「作成プロセス」と「ビジネス ロジック」を混同していることです...1. hello world を出力します。 2. int a と int b の合計を計算し、それを出力します。
現時点では、スレッドの作成プロセスを変更する必要があることに注意してください。つまり、開始関数を変更する必要があります。 リーリー
この議論は終わりです。注意深く観察しましょう...実際:
リーリー
コードのこの部分は変更されず、必要に応じて開始関数のコードのみが変更されます。
それでは、変更されたコンテンツのこの部分をインターフェースにパッケージ化できますか? ?
これは良いアイデアになるはずです!
リーリーもう完全に理解できたかわかりませんが? :D
はは、Java の Thread クラスは、Runnable パラメーターを備えたコンストラクターを提供するだけではないでしょうか?
ビジネス コードを Runnable インターフェイスの実装クラスに追加します。
リーリーそれで、最終的には次のように呼び出すことができます:
リーリーこれでスレッドの「作成プロセス」と「ビジネスロジック」の完全分離が完了しました!この「分割」により、Java スレッド プール テクノロジへの道も開かれました。
正直に言うと、サンプルコードの Thread t = new Thread() { ... } は十分簡単ですが、スレッド プールに Thread を作成するのはそれほど簡単ではありません。
だから「分割」はとても必要なのです!
また、次のように想像できますか?
リーリーRunnable 実装クラスに Runnable リストが含まれている場合はどうなりますか?
概要:
1. Runnable インターフェイスを使用する目的は、スレッドの「作成プロセス」をスレッドの「実行ロジック」から完全に分離することです。
2. スレッドはリソースを共有できますが、このステートメントは正しくありません。 ;
3. 議論の中で、私は具体的なものから抽象的なものへと移行しました。
さて、上記はこの質問に対する私の答えです。お役に立てば幸いです。