Javaに関する10の嘘

Java プログラミング言語

java は、クロスプラットフォームのアプリケーション ソフトウェアを作成できるオブジェクト指向プログラミング言語です。これは、1995 年 5 月に Sun Microsystems によって開始された Java プログラミング言語および Java プラットフォームです (つまり、JavaEE (j2ee)、一般名)。 JavaME(j2me)、JavaSE(j2se))。

以下の質問は比較的高度な質問とみなされ、面接官を遠ざける可能性があるため、面接ではめったに聞かれません。しかし、時間を見つけて自分で練習することはできます。

1. System.exit(0) は、finally ブロックの実行をスキップします

System.setSecurityManager(new SecurityManager() {
        @Override
        public void checkExit(int status) {
            throw new ThreadDeath();
        }
    });
    try {
        System.exit(0);
    } finally {
        System.out.println("In the finally block");
    }

なぜこのコードは、finally ブロックで出力されるのでしょうか?スタック トレースが出力されないのはなぜですか?

2. String str = "Hello"; ここで、str は文字列オブジェクトです。C++ とは異なり、Java の変数は基本型または参照です。変数をオブジェクトにすることはできません。これは次のような表現を意味します:

String str = "Hello";
    String text = "Bye";
    str == text; // 比较两个引用，而不是内容
    str = text; // 把text的引用赋值给str

ほとんどの場合、大きな違いはありませんが、このように書くと混乱を引き起こす可能性があります。

final StringBuilder sb = new StringBuidler();
    sb.append("Hello"); // 这个引用是final类型的，而不是这个实例。
    method(sb); // 可以通过方法来修改这个实例，不过这个变量是无法修改的

3. Java のメモリ リークは、C++ プログラマーが理解しているものと同じです

Wikipedia のメモリ リークの定義は、「コンピュータ サイエンスでは、プログラムがメモリ割り当てを正しく管理しない場合、メモリ リークが発生します。オブジェクトでは、指向プログラミングでは、コードからメモリ内のオブジェクトにアクセスできない場合、これはメモリ リークです。「しかし、Java では、オブジェクトは常に到達可能であり、強参照のないオブジェクトはクリアされます。 Java におけるメモリ リークという用語は、メモリ内に存在すべきではないオブジェクトが存在することを意味します。通常は、使用されなくなったがコレクションにまだ格納されているリソースが含まれます。

4. マルチスレッドプログラミングは難しい

経験がないと、マルチスレッドプログラミングは確かに難しいです。実行のために大量のコードを多数のスレッドに投入するだけでは、問題を解決する方法はなく、混乱するだけです。 しかし、オンデマンドでスレッドを割り当て、スレッド間の対話を制御し、チームのメンバーが理解できるいくつかの単純なパターンを使用できれば、問題ははるかに単純になります。もちろん、もう 1 つの課題は、チームの全員に自分のルールに従わせなければならないことです :-)

5. 異なる操作間のパフォーマンスの違いについて心配する必要はありません

最近、相関関係に関係する問題について聞きました。整数の加算、メモリアクセス、モジュロ、およびコンソールへの出力。これらの各操作は前の操作よりも一桁遅いですが、この男は、最も高速な操作である加算を最適化し、それをより高価な操作に置き換えたかっただけです。 本当にパフォーマンスを最適化したい場合は、ボトルネックがハードウェアにある場合、たとえば、ハード ディスクから大量のファイルを読み取ってソフトウェア コードを変更する必要がある場合は、これらの高価な操作を安価な操作に置き換えたほうがよいでしょう。問題はまったくないので、役に立ちません。

6. 乱数はランダムです

特定の乱数のセットは、特定の数字のパターンのようなものです。この問題については、この記事ですでに説明しました。多くの人は、乱数発生器によって生成される数値が実際には非ランダムであるとは信じていません。

7. 浮動小数点数はランダムなエラーを生成するため、できるだけ避ける必要があります。

同じ演算の場合、浮動小数点数は毎回同じエラーを生成します。間違いは予測可能であり、したがって制御可能です。自分が何をしようとしているのかを理解し、結果の四捨五入などの単純なルールに従えば、BigDecimal よりも浮動小数点数のほうが間違いを犯すことはなくなり、さらに読みやすく、より堅牢になります。 100 倍以上高速になります (同時に生成されるガベージ オブジェクトの数も少なくなります)。

8. タイムゾーンは永遠です

この誤解の理由は、時間の変化とともにタイムゾーンも変化するためです。これは、新しい元号のヨーロッパ/ロンドンが 00:00 ではなく 1970/1/1 01:00 であることを意味します。なぜですか?ロンドンでは 1968 年から 1971 年まで夏時間を採用していたためです。

過去数年で、多くのタイムゾーンも変更されました。モスクワは以前は東 3 地区 (GMT+3) でしたが、現在は東 4 地区 (GMT+4) です (2011 年 3 月 27 日から)。 2010年当時を見ると東4区ではなく東3区になっていることが分かります。

あなたにとって驚くべきことは他にもあります:

1721 年のスウェーデンの 2 月は 30 日でした。

1751年のイギリスの初日は3月25日で、フランスより11日遅れでした。

米国がグレゴリオ暦を採用した後、数百年前に遡り、最初に記録された日付を 2 つのカレンダーで表すことができるようになりました (通常は、より正確にするために 2 つの日付が同時に提供されます)。たとえば、ジョージ ワシントンの誕生日は 1731 年 2 月 11 日から 1732 年 2 月 22 日に変更されました。

9. スレッド内で不揮発性変数を読み取ると、最終的にはその更新された値を読み取ることができます。

この質問は数日前に StackOverflow に 2 回表示されました。一般に、JIT コンパイラはコードを最適化するときに、このスレッドによって変更されていない不揮発性フィールドをインライン化します。このコードがコンパイルされると (-XX:+PrintCompilation を通じて確認できます)、別のスレッドでこのフィールドに加えた変更はおそらく表示されなくなります。ランダムな同期ブロックまたは print ステートメントを追加すると、この最適化の実行が遅れたり、JIT コンパイラーが混乱してこの最適化が実行されなくなる可能性があります。

10. Java の面接の質問はすべて正しいです

Java の面接の質問には、古い (10 年以上更新されておらず、現在の Java バージョンと一致していない) か、誤解を招く可能性のある質問がたくさんあります。間違っても。残念ながら、これらの回答はチェックされずに回覧されます。

ここでの回答の方が査読されているため、Stackoverflow の回答を参照します。一般に、rose india のようなウェブサイトは使用しないでください。上記の回答の質は驚くほど悪いです。さらに深く掘り下げたい場合は、上記の記事にスペルミス (クラス名や専門用語) や間違った記述がどれだけあるかを確認してください。これらの問題の理由の 1 つは、これらのエラーを修正する効果的なフィードバック メカニズムがないことです。

上記は Java に関する 10 の嘘の内容です。さらに関連する内容については、PHP 中国語 Web サイト (www.php.cn) に注目してください。