収集するために、シニアJavaのインタビューの質問

Javaの概念のタイトル

原則の開梱箱

valueOfがプリミティブ型にコンパイラ類似intValue（）オブジェクトの種類の、のdoubleValue（）メソッドを呼び出すことによって、プリミティブ型に変換にオブジェクトをオートボクシング、そして自動的にアンパックコンパイラコール。

ダブル、フロートのみオートボクシングコードは毎回新しいオブジェクトが他の6つの基本タイプは、キャッシュポリシーを使用して、新しいもので、キャッシュを使用しません。

頻繁に自動包装を防止するために、（例えば、文字、127 -128の間の番号など）に使用されるキャッシュされたオブジェクトは、オブジェクトの各インスタンス一旦作成されるため戦略をキャッシュ使用です。

そして、ダブル、フロートはフロートは、キャッシュは、高効率のホット（頻繁に使用される）データのいくつかの他のタイプの、特に何も影響はないではありません、です。

反射、クラスのインスタンスを作成するための反射の原理

情報のクラスの型を取得するために、実行時に動的にできます

3つの方法でクラスオブジェクトクラスを作成します：

对象.getClass()道
类名.Class道
Class.forName( 类的包名 ) 道

遅い反射性能上の理由

名前は、クラスやメソッドを取得する必要性を反映することにより、一定時間のオーバーヘッドがあります。
反射型が関与する動的なプロセスは、いくつかの仮想マシンは、パフォーマンスの最適化を実行することはできません。

ディープと浅いコピーコピー

基本的なデータ型がコピーされたが、唯一の参照データ型のされているオブジェクトのコピーは参照を渡した場合は、しかし、本当の新しいオブジェクトを作成し、浅いコピーであると考えられていません。データ型の参照コピーは、新しいオブジェクトを作成し、その中にメンバ変数をコピーし、逆に、その深いコピーです。

実装Cloneableインタフェース複製clone()方法を、それは浅いコピーを達成しています

春のコンセプトのタイトル

春AOPとIOCの原則

IOC：

IOC（反転制御）システムは、ある程度ではなく、スプリングの特許にオブジェクトを結合する高すぎる程度の複雑な問題を解決することができ、プログラミングパラダイムです。最も一般的な方法は、IOC DI（依存性注入）にあり、コンテナによって、Beanが直接他の場所で、将来の使用のためにそれを維持するのではなく、再新しいです。

なぜDIは、デカップリングの役割を果たすことができますか？
多数のオブジェクトを含むソフトウェアシステムは、各オブジェクトは、製造プロセス中に、唯一のクラスのコンストラクタを介して、オブジェクト間のさまざまな依存関係の間で分散共通のソフトウェアオブジェクト定義ファイルの依存関係を有しますパラメータ渡し、フォームを完了するために、パラメータ渡し方法。プロジェクトが大きい場合、オブジェクト間の複雑なロジックの依存関係は整理することが非常に困難になります。
一般的には春IOCでは、我々はXMLファイルで、豆、豆と豆の統一された定義の作成間の依存関係は、このように、論理の明快さを増すことができます。また、完了するために、春が作成したBeanは、プログラマがプログラマだけ思考の負担を軽減し、上記のビジネスロジックに集中する必要がある、心配する必要はありません。

ときにアプリケーションを読み取ることスプリングビーンブート構成情報を提供し、レジストリに配置された対応するBean Springコンテナを生成し、その後、レジストリ豆のこの実施例によれば、上位のアプリケーションのために、ビーン間の依存関係を組み立て準備操作環境を提供します。

豆バッファプール：HashMapのは、達成

保存されたクラス属性予めビーン・バッファ・プール（ハッシュマップ）の設定メソッドがクラスのクラスに注入されることクラスをインスタンス化すると、反射によって呼び出されたとき依存性注入の概念は、反射によって達成されます。

AOP：

、CGLIBが使用するフレームは、バイトコードのこの直接操作をASM、インタフェースを実装していない行うことができる原理は、実際にAOP Javaの動的なプロキシですが、このライブラリCGLIBスプリングAOPが実装されているので、JDKの動的プロキシは、インターフェイスを実装する必要があります場合の動的プロキシの完全な。

たBeanFactoryの春とFactoryBeanの違い

MyBatisの基礎をなす原則

スプリングコントローラは同時の安全性を確保する方法を、単一のケース又は複数のケースであります

デフォルトのコントローラが単一の場合で、それ以外のデータは、論理的な混乱を発生します、非静的メンバ変数を使用しないでください。
それはシングルトンスレッドセーフではありませんので。

サプリメント
のSpring Beanのスコープは、次の5つがあります。

シングルトン：シングルトン、春のApplicationContextのコンテナは、春を回避レイジー初期化の前処理で、すべてのスコープのインスタンスを初期化したいときに作成されます。
プロトタイプ：プロトタイプモード、それぞれの春は、もはやその経営を作成し、Beanを取得getBeanして、新しいインスタンスを生成しません。

（以下は、唯一のプロジェクトのウェブで使用されています）

リクエスト：我々はすべてのことを理解しておく必要があり、要求のうちウェブドメイン、各要求新しいインスタンスを、さまざまなプロトタイプが春はまだ聞いて、次の投与後に作成されたということです。
セッション：セッションごとに、前出 ;
株式会社フリー参加するグローバルウェブドメイン、アプリケーション内のサーブレットに類似：セッションを。

インターネット概念の質問

TIME_WAIT状態とCLOSE_WAIT差

三つの状態が使用される：ESTABLISHED通信示し、TIME_WAITはCLOSE_WAITパッシブ近いを示し、積極的に閉じ表します。

TCPプロトコルは解放されませんこれらのステップの1の欠如が仮死状態の接続を行います場合は、接続が確立された、両方のネットワークが成功するために切断さ4ウェイハンドシェイクするために、接続リソースは、それ自体で占められています。ウェブサーバプログラムが多数の接続を管理するために、接続が完全に役に立たない切断されている、または死んだ多数の接続は、サーバリソースの多くを無駄にすることを確実にすることが必要です。CLOSE_WAITやTIME_WAIT：多くのTCPの状態の中で、最も顕著な状態には2を持っています。

TIME_WAIT

アクティブリンクは、4分程度、2MSL待機時間を閉じたときにTIME_WAITが形成されています。主に、最後のACKの損失を防ぐため。TIME_WAIT時間が非常に長くなり、したがって、サーバ側アクティブクローズ接続を最小にしなければならないため

CLOSE_WAIT
近い接続が形成CLOSE_WAITの受動。TCPステートマシンは、サーバーは、クライアントは、このようにCLOSE_WAIT状態に入る、FIN、ACK送信に応じてTCPの実装を送り受け取ります。サーバは、close（）を実行しませんCLOSE_WAIT LAST_ACKに移行することはできません場合は、本システムは、多くのCLOSE_WAIT状態に接続されます。この時点で、システムは、FINを受信した接続せず、ビジー処理の読み取りおよび書き込み操作すること、および閉じることができます。FINが受信されたこの時点、RECV /読み込み接続ソケットで、それは0を返します。

なぜTIME_WAIT状態？
最後のACKが失われたと仮定すると、サーバーは、サーバーエラーの結果発生を検討し、それ以外の場合は、RSTを送信します、TCPは、最終的なACKを再送することができるためFINは、クライアントが状態情報を保持しなければならない再送信します。TCPの実装が確実双方向（全二重オフ）を終了するように接続されなければならない場合は、クライアント最後のACKが再送信された顔できるように、クライアントは、TIME_WAIT状態に入る必要があります。

なぜ2MSL TIME_WAIT状態は、このような長い時間を維持する必要がありますか？

RFC 793 [ポステルの1981c]はMSLは2分であることが判明しました。しかし、従来の実装値は30秒、1分、または2分です。

2MSL即ち二回MSL、TCP TIME_WAIT状態はまた、第三のハンドシェイクACKパケットの終了が第ハンドシェークを送信した後にTCPの端部が積極的に、すなわち、最後のACKパケットを送信した後、閉じ開始すると、待ち状態2MSLを参照されTIME_WAIT状態に入った後、あなたは、この状態で2倍の時間MSL滞在しなければなりません。
時間2MSL主な目的を待って受信されない互いに最後のACKパケットを恐れて、その後、他の再送三握手FINパケットがタイムアウト後、その後FIN ACK応答パケットを送信することができ再送パケットの終了後にシャットダウンするためのイニシアチブをとります。
TIME_WAIT状態の両端のポートは、使用を継続する時間2MSLの終わりまで使用することができません。
接続がある場合には何の待機期間の2MSL後半セグメントは破棄されません。しかし、実用的なアプリケーションでは、あなたは、オプションSO_REUSEADDRリーチを設定することで、このポートを使用する前に、2MSL時間の終了を待つ必要がないかもしれません。

TIME_WAITと* CLOSE_WAIT *ステータスソケットすぎ

サーバーが異常、九十八%外の場合は、次の2例です：

1.サーバーがTIME_WAIT状態の多数を維持

2.サーバーが大CLOSE_WAIT状態を維持し、短期では、不適切な取り扱いへの接続を閉じるには余りにもパッシブCLOSE_WAITの数が多いためです。

Linuxのユーザのファイルハンドルに割り当てられているため制限されており、TIME_WAITとCLOSE_WAIT二つの状態が維持されている場合は一度「ハード他人の利益」、それは、チャネルの対応する数は、それが占有されていることを意味し、そしてありますハンドルの最大数は、新しい要求が異常オープンファイルが多すぎる、Tomcatのクラッシュの大多数が続き、に対処することはできません。

概念質問のRedis

競争のRedisで何を複雑にしていますか？どのようにこの問題を解決するには？CASは、業務プログラムが行うRedisの学ぶのか？

この行は、非常に一般的な問題があるにもあるマルチクライアントの同時書き込み、キーの後におそらく最初のデータの間違ったバージョンにつながる、データに来ているはずです。あるいは、複数のクライアントが同時にキーを取得して、後に値を変更します順序が間違っている、間違ったデータである限り、ライトバック。

ソリューション

飼育係分散ロックを達成
あなたは、キャッシュされたデータを記述する必要がmysqlのから発見され、mysqlは書かなければならなかった、書き込み時間のMySQLはタイムスタンプに保存する必要があり、MySQLの時間をチェックアウトし、また、タイムスタンプをチェックしてください。
あなたが望むたびにあなたが書く前には、最初に決定したタイムスタンプの現在の値がキャッシュの値のタイムスタンプよりも新しいものを。もしそうなら、あなたが書くことができ、そうでない場合は、古いデータが新しいデータをカバーするために使用することはできません。

MySQLの概念質問

MyISAMテーブルとInnoDB内Mysqlの違い

InnoDBはトランザクションをサポートし、MyISAMテーブルがトランザクションをサポートしていません。これは、MySQLがMyISAMテーブルからInnoDBのにデフォルトのストレージエンジンになります重要な理由の一つです。
サポートInnoDBの外部キー、およびMyISAMテーブルはサポートしていません。MYISAM失敗にInnoDBの外部キーを含むテーブルの場合、
InnoDBは、クラスタ化インデックスで、MyISAMテーブルは、非クラスタ化インデックスです。主キーのインデックスのリーフノードに格納されているクラスタ化インデックスファイルは、InnoDBはそれゆえ、主キーを持っている必要があり、主キーのインデックスは非常に効率的です。しかし、それは二つの補助インデックスクエリ、主キーの最初のクエリを必要とし、主キーによってデータを照会します。そのため、主キーは、主キーが大きすぎるので、他のインデックスも素晴らしいものだが大きすぎてはなりません。非凝集のMyISAMインデックス、別のデータファイルに対し、インデックスポインタは、データファイルに格納されています。プライマリキーインデックスとセカンダリインデックスは独立しています。
テーブル内の行のInnoDB特定の番号がSELECT COUNT（*）を実行し、保存されたテーブルからフルテーブルスキャンを必要とされていません。速い、変数にREAD文を実行するだけで、テーブル全体を保存する行の数が可変とし、MyISAMテーブル、。
InnoDBの最小行ロックは、粒度をロック、ロック粒度は最小MyISAMテーブルロックです。更新文がブロックされている他のクエリと更新につながる、テーブル全体をロックしますので、同時アクセスが制限されています。これがデフォルトのストレージエンジンMySQLはMyISAMテーブルからInnoDBのための重要な理由の一つになるだろうです。

政策課題

そこのデータはRedisの中にホットデータであることを確実にするためにどのように2000ワットMySQLデータ、Redisの20ワットに保存されたデータのみ、？

LRU（最低アウト使用）：これは、キャッシュ無効化の概念の簡単な実装を提供する
TTL（時間が満了）（例えば10分などの特定の状況に応じて設定）をヒットすなわちRedisのキャッシュは毎回ヒット、キャッシュ内の特定の増加を与えます。
いくつかの時間後に、データをTTLます熱が大きく、それは、実質的に即座に無効に設定冷たいのTTLデータ上で、自動的に有効期限はありません。

政策のうち申し出6つのデータをRedisの：

データセットのRedisのメモリサイズは、特定のサイズに上昇すると、彼らはデータ消去戦略を実行します。Redisのアウトポリシーデータは、6を提供する：
揮発性LRU：最も最近のデータからデータセットを選択するために使用されるに有効期限を（server.db [I] .expires）を設定
揮発性-TTL：有効期限は、データセットから設定されています（server.db [I] .expires）のうち古いデータであるように選択された
揮発性ランダム：任意にセットアウト有効期限データセット（server.db [I] .expires）からのデータを選択
データ：allkeys、LRUセット（server.db [I] .dict）が最低使用頻度のデータの中から選択した
allkeysランダム：データセット（server.db [I] .dict）を任意のデータを選択し
、無enviction（追放）は：追放を禁止しますデータ

分散一意のID

UUID

核となるアイデアは、UUIDを生成するためのレコード番号で、マシンカード、ローカルタイムを組み合わせることです。

シンプルを生成するために、ローカルで生成され、良好なパフォーマンス、高可用性リスクなし：メリット
短所：あまりにも長い間、冗長メモリ、およびランダム読めない、低検索効率

データベースの増分ID

このようMySQLのAUTO_INCREMENTとして使用するデータベースIDの増分戦略、。そして、2つのデータベースは高可用性を実現するために、長い一意のIDが生成された戦略を同期されていない使用して提供することができます。

長所：データベースで生成されたIDは、高可用性を実現するための方法絶対に秩序と簡単です
短所：別のデータベースインスタンスを展開する必要性、高コスト、パフォーマンスのボトルネックがあります

バッチ世代ID

要求IDにバッチを複数生成し、各ビルドがデータベースへの必要性へのアクセスである、データベースはIDの最大値に変更し、現在の値とメモリの最大値を記録しています。

利点：データベースにアクセスするために、すべての世代IDを回避し、パフォーマンスを向上させるための圧力を持参しなければなりません
短所：ローカル生成戦略に属する、リスタートIDのサービス中断に起因する単一障害点があり、

ジェネレーションIDのRedis

Redisのは、すべての操作は、INCRとしてご自身をシングルスレッドであり、そのような自己コマンド吸着原子increby、彼らは唯一の秩序である必要があります生成されたIDを確保することができますコマンド。

利点：柔軟かつ便利なデータベースに依存し、データベースに優れていません。自然の注文ID番号が、結果はソート]タブまたは有用にする必要があります。
短所：システムは、システムの複雑性の増加、のRedisに、新しいコンポーネントを導入する必要がない場合は、努力に符号化されると、設定の必要性を。

単一ノードのパフォーマンスのボトルネックを考慮すると、クラスタはRedisのをより高いスループットを得るために使用されてもよいです。クラスタは5つのRedisのを持っている場合。Redisの値のそれぞれを初期化することができる1、2、3、4、5であり、5はステップです。Redisのは、それぞれのIDを生成しました：

A：1, 6, 11, 16, 21
B：2, 7, 12, 17, 22
C：3, 8, 13, 18, 23
D：4, 9, 14, 19, 24
E：5, 10, 15, 20, 25
复制代码

ちょうど良いですどのマシンかを決定するためにロードし、将来的には変更を加えることは困難です。ステップ必ずしも予め決定された初期値。使用Redisのクラスタリングの問題が失敗の道シングルポイントすることができます。

さらに、0から始まるシリアルRedisの日を生成するために、より適切な使用。このような成長番号以降の注文番号=日+日など。キーは、累積INCRを使用してのRedisに毎日生成することができます。

Twitterのアルゴリズムスノーフレーク

：TwitterはグローバルIDサービススノーフレーク生成github.com/twitter/snoを...

上記に示した、ツイッタースノーフレークアルゴリズムは、次のコンポーネントで表されます。

符号ビット：

Javaでの長いタイプは、最上位ビットは符号ビットであり、nは0で署名されているので、1は負であり、かつ使用される実際のシステムIDは、一般的に陽性である、最上位ビットは0です。

（ミリ秒単位）41のタイムスタンプ：

IDは、スタンプジェネレータは、典型的に始まる開始時刻である、 -タイムスタンプ41は、現在時刻のタイムスタンプが、記憶されたタイムスタンプ（タイムスタンプの開始現在のタイムスタンプ）との間の差を記憶されていないことに留意すべきですタイムスタンプは、41ミリ秒の最大値は、タイムスタンプを使用することができるように、プログラムを指定するために使用されます(1 << 41) / (1000x60x60x24x365) = 69年。

10個のデータビットマシン：

5つの備えるデータ識別ビットおよび10まで展開させることができる分散システムを判断する5ビットのマシンID、1 << 10 = 1024Sノード。この数は、生成されたIDが競合する可能性があり、超えています。

順番に12ミリ秒：

生成するには、このサポートミリ秒ごとに各ノード数の12（同じマシン、同じ時間）まで 1 << 12 = 4096个ID

まさに64、ロングタイプまで追加。

利点：

1）データベース、柔軟性、および優れたパフォーマンスデータベースに依存しません。

2）単一のマシン上で時間のIDをインクリメントします。

短所：

1）単一のマシン上で増加しているが、それは、分散環境に関連し、各マシン上のクロックが完全に同期することができない、多分時々グローバルが増加する場合ではありません。

データベースの生成

MySQLの例では、フィールド設定を使用auto_increment_incrementし、auto_increment_offset自己増力IDことを確実にするために、各サービスMySQLは、以下のSQLは、ID番号を読み取る使用して得られました。

begin;
REPLACE INTO Tickets64 (stub) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;

次のようにこのアプローチの長所と短所は以下のとおりです。

利点：

既存のデータベースシステムの機能実現、小型のコスト、DBAプロのメンテナンスを使用して、非常にシンプル。
ID番号は、サービスIDのためのいくつかの特別な要件を達成することができ、単調にインクリメント。

短所：

システムが利用できないときに強い依存性DB、DB異常は、致命的な問題です。マスターコピーから、例外的な状況でのデータの一貫性を確保することができるが、難しいの可用性を高めるように構成することができます。主な矛盾から切り替えた場合、重複Faを生じ得ます。
単一のパフォーマンスのボトルネックで発行されたID番号が読み取りと書き込みのパフォーマンスMYSQL。

次のようにMySQLのパフォーマンスの問題のために、解決策が利用可能である：分散システムでは、より少数のマシンを展開することができ、各マシンが、異なる初期値とステップサイズとマシンの同じ数を設定します。例えば、2台のマシンがあります。ステップ2の設定ステップ、初期値1 TicketServer1（1,3,5,7,9,11 ...）、2の初期TicketServer2値（2,4,6,8,10 ...）。

米国ミッションリーフ

リーフは、オープンソースの分散グループIDジェネレータの美しさで、グローバル一意性を保証するために、傾向はまた、リレーショナルデータベースに依存する必要があり、いくつかの分散型アプローチの比較を述べたが、情報セキュリティ、飼育係のミドルウェア、単調増加インクリメントされ。

具体的に公式サイトの説明を参照してください。tech.meituan.com/MT_Leaf.htm ...

参考：

2019最新のアリ補間シニアJavaのインタビューの質問

春IOC原則概要