Javaeeフィールドを長い間支配してきた足場は、Spruts2 Mybatis/Hibernateでリードしています。
春：
春はJavaサービスだけではありません。 SpringのCGI標準としての実装として、それはJavaフィールドのフレームワークであるだけでなく、C＃プラットフォームは引き続き利益を得ることができます。 Springは、抽象化やBootde統合ソリューションなどのさまざまな便利な注釈構成方法を提供します。これにより、Javaeeのプロジェクトベースが大幅に簡素化されます。
春の使用中、両側は区別され、一部は軽量の注釈であり、一部は完全な注釈になりがちです。
まず第一に、注釈の前提は、プロキシ、ダイナミック、静的、およびCGLIBプロキシを通過する必要があるということです。軽量注釈の場合、角度は静的または1回限りの注釈です。
たとえば、コントローラーアノテーション、これらの1回限りの注釈またはコンパイル時間アノテーションは、プロジェクトのコンテキストで暗黙の1回限りのスキャンとして初期化され、Singleton Lightweight Objectインスタンスを提供するサービスなどの関連注釈が提供されます。最初の選択肢と見なされます。これにより、ランタイム期間中のプロキシと反射のコストが削減され、ランタイムスタックのリソースが向上します。
ResponseBodyなどの別のタイプは、動的な注釈またはランタイム注釈です。要求するたびに、注釈の反映が実行されます。実行期間の注釈は、もちろんリソースを占有することです。
一般に、必要な注釈は完全に無視できません。サーブレットの基本に基づく要求と応答の方法に基づいて、MVCはなく、パラメーターを取得し、パラメーターを渡し、返すなどを解決できません。ランタイム中に注釈は必要ありません。ランタイム中の注釈は、コードの量を減らすようです。このプロセスのさまざまな欠点を補うために、メソッド内で使用する注釈を実行するために、円の動的な注釈が実行されます。メソッドに記述されたパラマンアノテーションの場合、リクエストを使用することと比較してどのコードが欠落していますか？コード傍受の層を追加するために、元のワンステッププロセスが追加されたというだけです。
アノテーションが実行時の注釈であるかコンパイル期間の注釈であるかを知る方法は非常に簡単です。 Ctrl+マウスをクリックすると、次のように表示されます。
@Target（{elementType.Type、elementType.Method}）
@retention（RetentionPolicy.Runtime）
@documented
この列挙タイプは、使用する注釈の期間を完全に明確に示しています。
誰もが春のシングルトンを使用するのが好きです。これは優れた方法です。シングルトンは、リソース識別のために競争させる必要があることを除いて、同時性自体とは何の関係もありません。
プロジェクトに多くのプロトタイプオブジェクトが必要な場合は、間違ったオブジェクトを乱用または使用したことを意味します。 MVCには、基本的に着信パラメーターとリターンがあります。各リクエストはスレッドです。個別の要求応答には、入力して終了するものがあります。これは完全に分離されています。このことから、MyBatisに関しては、多くの人がMyBatis構成でさまざまな再マッパーを使用し、そのたびにさまざまな豆が行き来します。リクエストの後、パラメーターと結果としての豆は1回必要です。 MyBatisの表面は、JDBCの効率を大幅に低下させるためのSQLメンテナンスに対して明確です。その後、誰もそれを気にしません。彼らにとって、豆には何もありません。彼らはGCを理解したり気にしたりしません。問題が発生した場合は、メモリを追加してメモリを上部に追加します。彼らが解決するのは、時間の問題であり、時間を使用して時間を交換します。同じパラメーターと結果マッピングを使用すると、JDKのマップを使用する場合は、自然にJDK独自のマップです。
私は常に、新しいJDK自身のオブジェクトの消費が自分で豆を定義するよりもはるかに小さいと常に信じていました。なぜ、申し訳ありませんが、私も知りません。だから私はいつもマップとマップGoに来ます。 MyBatisを使用するとき、あなたの物事があなたのクラスに誘われているかどうかを厳密に検出する必要がありますか？この方法は非常に簡単です。プロジェクトログで、デバッグを開いて、ログが毎回新しいsqlsessionが作成されているかどうかを確認します。この場合、MyBatisセッションはプールされておらず、物事に賛成されていないことに注意する必要があります。メソッドに競争力のあるSQLがある場合、申し訳ありませんがエラーはありませんが、データベースはSQLを実行しないことがわかります。すぐに、接続プールが非常に迅速に使用され、頻繁に新しい接続を作成することがわかります。もちろん、MyBatisを使用できない場合は、躊躇しないでください。使用しないのは正しいことです。
なぜ静的注釈を使用しようとする必要があるのですか？とても簡単です。春のクラスは基本的にシングルトンです。プロジェクトは十分に大きく、Beanインスタンスで十分です。これらのシングルトンは何を取りますか？オブジェクトインスタンスはヒープスペースにあり、スタックで参照されます。では、GCはこれらのシングルトンからオブジェクトをリサイクルするのはいつですか？あなたが思うこと？したがって、注釈に基づいている場合は、動的プロキシの使用を最小限に抑えるようにしてください。必要に応じて使用するために、より多くのリソースを残してください。
過去には、ヒープはありませんが、今ではJDK1.7の文字列定数プールがすでにヒープに入っています。
コンピレーションタイプまたは解釈可能性のどちらが良いですか？もちろん、それは分析的であり、コンピレーションタイプは調停モデルに似ています。したがって、解釈された言語よりも優れたコンパイルされた言語を構築することははるかに困難です。
Webの構造は非常に明確です。まず、それはまだコンテキストにあり、次に一連のコンポーネントが順番にあります。私たちが最も重要なのは、Javaee標準であるサーブレットコンポーネントであり、Webコンポーネントの残りの部分はプロトコル標準であり、誰もが持っている必要があります。そうすれば、多くのプロジェクトでのサーブレットのマッピングが /、これは悪い方法であることがわかります。非常にシンプルであるため、JSまたはCSSはサーブレットを介して処理する必要はありません。したがって、マッピングは主にWebコンテナのサーバーコンポーネントとの相互作用を考慮し、通常、.doや.cactionなどの2種類の識別を提供します。 JSなどはサーブレットを入力する必要はなく、URLに従ってWebコンテキストから直接戻る必要はありません。その後、MVCをMVCに傍受して放出する方法はありません。これは問題を引き起こし、問題を解決するのに時間の無駄ですが、これは良い方法ではありません。このように、Nginxが関与しているかどうかに関係なく、静的リソースはWebコンテナの静的であり、サーブレットと関係がありません。サーブレットは、処理する必要があるものにのみ関連しています。
JSを書くのに最適な場所はどこですか？
多くの人々は、JSPまたはHTMLでJSを書くことに慣れていますが、これは悪いことです。
プロジェクトを構築するとき、JSとCSSがブラウザによってキャッシュされることを願っています。
次に、ページのスクリプトタグに書かれたJSは単なるタグであり、Divや入力と違いはなく、キャッシュされません。私は多くの情報をチェックしました、そして、私が見たキャッシュは明らかにキャッシュユニットがファイルであると言った。ラベルではありません。したがって、CSS JSをファイルに書き込み、ファイルを導入してファイルを導入することは完全にはわかりません。直接的な肯定的な答えがないため、それは私の推測です。
JSPは実際にはサーブレットなので、動的なページです。動的に翻訳するためにクラスをロードする必要があるたびに、クラスの書き込みメソッドがページをHTTPにブラウザに書き込み、ブラウザをレンダリングします。 HTMLの場合、静的です。動的で柔軟に、それがサーブレットであるため、それはJavaオブジェクトであり、さまざまなJavaタグと方法が可能性と呼ばれることは間違いありません。静的ページは自分で処理する必要があります。静的ページに似たマクロ言語を使用する場合は、JSPを直接使用する方が良いでしょう。
ページ上の一度にどのくらいのデータがロードされますか？
ページに表示されるコンテンツがカテゴリとリストに基づいている場合、データの量は非常に少なく、数百のアイテムがあります。このタイプは、Takeaway Orderアプリに表示され、すべてのカテゴリとデータが一度に与えられます。したがって、処理はクライアント側で処理され、プロセス全体のカテゴリの切り替えとプレビューは、検索を含むページで処理されます。クライアントで実行されたJS、Aの携帯電話またはコンピューターは、Bの携帯電話やコンピューターと競合しません。タイプに切り替えるたびにタイプを切り替えると、Ajaxをブラッシュすると同じWebコンテナグループであるため、競争が行われます。操作が頻繁になるほど、競争が大きくなります。これは、実際のシナリオに密接に関連しています。
クエリによって返されるデータの量は、パフォーマンスとは関係ありません。数千のデータは、数十KBのレベルにのみあります。
クエリの数、つまりサーバーとのやり取りの数は、全体的なパフォーマンスに影響する直接的な理由です。
クエリ内のデータの量は、照会されたテーブルのサイズに比例します。一度に10個のクエリを返し、一度に10個のクエリを返すことでクエリをスピードアップし、クエリを遅くします。データベース操作は基本的にコレクションアプリケーションであり、何も作成されません。
チューニングの前提は、与えられた量が最も適切であり、あなたが与えるほどではなく、それがより適切であるということです。 JDKまたはTomcatがOSの異なる桁で消費できるメモリ。
nginxを使用します。
必要に応じてキャッシュを使用します。
必要なかどうかに応じて、メッセージミドルウェアまたはその他のミドルウェアを選択します。
データベースやマスタースレーブなどの分離は、現在のデータベースがトラフィックボリュームをサポートできないことです。
シングルトンは良い方法です。
マルチスレッドは鋭い刃であり、特定の言語を区別しません。
Maven Managementは良い方法ですが、プロジェクトの本体はWebMVCであり、Webプロジェクトを構築し、Mavenプロジェクトを作成し、アイドル状態でない限り、Webプロジェクトに変換する代わりに、Mavenをコンポーネントとして埋め込む必要があります。
Springを使用すると、現在最高の足場です。
可能であれば、できる限りJDBCを使用してください。
クライアントで物事を達成できるときは、サーバーとやり取りしないでください。クライアントのリソースは膨大であり、サーバーのリソースは限られています。
より少ないリクエストを送信してみてください。あなたがインスタントアプリケーションでない限り、より少ないリクエストを送信するコードは良いコードです。
各コードのツールはツールであり、APIは最も理解するために必要なものです。どちらが優れているのか、どちらが良くないかについての正確な答えはありません。
すべてがオブジェクトであり、Javaにとっては純粋です。プロキシはオブジェクトであり、反射はオブジェクトであり、オブジェクトはオブジェクトであり、基本的なデータ型はオブジェクトではありません。
基本タイプ以外のものは、オブジェクトを介して完成します。プロセスがどれほど複雑であっても、それらは対応するオブジェクトメソッドとメソッドパラメーターを組み合わせて完了します。クラスをシリアル化し、それをゆるくする方法、それを率直に言うために、それはファイルのIOと送信であり、それをJVMにロードしてオブジェクトに構築します。
RPCがスレッドで呼び出されない理由。呼ばれるものはプロキシです。プロキシは、ニーズをパラメーターに変換し、データストリームとして送信します。サーバーは、リクエストストリームをオブジェクトに変換し、それらを戻します。次に、オブジェクトを構築し、オブジェクトを介して処理します。
NIOは良い方法です、Nettyは良い選択です、Nettyを上回るマルチスレッドソケットはありますか？
Zookeeperは、適切な分散登録など、一連のソリューションに最適なツールです。
これらのものはすべて原則とオブジェクトなので、それらを使用して激しく読む必要があります。
上記は個人的な理解であり、あなたはそれを修正することを歓迎します。