JAVAEE プロジェクトの構造と同時実行性の考え方

長い間 javaee 分野を支配してきた足場は、spring struts2 mybatis/hibernate によって主導されています。

Spring:

Spring は Java サービスだけのものではありません。 CGI 標準の実装として、Spring は単なる Java 分野のフレームワークではなく、C# プラットフォームでも恩恵を受けることができます。Spring は、Javaee プロジェクトを大幅に簡素化する、抽象化や bootde 統合ソリューションなどのさまざまな便利なアノテーション構成メソッドを提供します。スプリングを使用するプロセスには 2 つの側面があります。1 つの部分は軽量アノテーションであり、もう 1 つの部分は完全なアノテーションに傾いています。

まず第一に、アノテーションの前提は、プロキシ、動的、静的、cglib プロキシを経由する必要があるということです。軽量のアノテーションの場合、パースペクティブは静的またはワンタイム アノテーションです。

コントローラー アノテーションなど、これらのワンタイム アノテーションまたはコンパイル時アノテーションは、サービスに関連する暗黙的なワンタイム スキャンとしてプロジェクト コンテキストで初期化されます。シングルトンの軽量オブジェクト インスタンスを提供します。第一選択と考えられます。これにより、実行時のプロキシとリフレクションのコストが削減され、実行時のスタックのリソースが節約されます。

もう 1 つのタイプは、動的アノテーションまたはランタイム アノテーションであるレスポンスボディです。リクエストが行われるたびに、アノテーションの反映が実行されます。実行時の注釈は当然ながらリソースを占有します。

一般に、アノテーションが必要ない場合は、サーブレットベースのリクエストとレスポンスのメソッドに基づいて、解決できない mvc、パラメータの取得、パラメータの受け渡し、戻りなどはありません。アノテーションは実行時アノテーションをまったく必要としないため、このプロセスのさまざまな欠点を補うために、メソッド内で使用するアノテーションを実行するために循環動的アノテーションが実行されます。メソッド内に記述されたparamアノテーションについて、request getを使用した場合と比較して不足しているコードは何ですか?元のワンステッププロセスにコードインターセプトの層を追加するだけです。

注釈が実行時注釈であるかコンパイル時注釈であるかを確認する方法は非常に簡単です。Ctrl キーを押しながらマウスをクリックすると、次のように表示されます。 Retention(RetentionPolicy.RUNTIME)

@Documented

Retention この列挙型は、使用するアノテーションの有効期間を完全かつ明確に説明します。

Spring を使用します。これは、プロジェクトのプロトタイプ オブジェクトにリソース識別の競合が発生することを除けば、シングルトンは同時実行性とは何の関係もありません。 、これは、MVC が基本的にパラメータを受け取って返すことを意味し、個別のリクエスト応答には受信したものと送信したものが完全に分離されています。 mybatis に関しては、多くの人が mybatis の 1 つの構成でさまざまな Bean を行き来しますが、そのたびに、パラメータと結果としての Bean は Mybatis 上で明確な SQL メンテナンスを行う必要があります。 jdbc の効率を大幅に低下させる代わりに、Bean を気にする人は多くありません。問題が発生するとメモリを追加したり、気にしたりしません。唯一の解決策は時間です。時間とスペースを交換することです。同じパラメータと結果のマッピングでは、新しい Bean を自分で作成して JDK のマップを使用するのが良いでしょうか? 当然、JDK 自体のオブジェクトを新しくするのはコストがかかると私はずっと信じてきました。自分で Bean を定義するよりもずっと簡単です。なぜなのか、申し訳ありませんが、私にもわかりません。だから私はいつも来るときも行くときも地図を描きます。 mybatis を使用する場合、自分のものがクラスにプロキシされているかどうかを注意深く確認する必要があります。その方法は非常に簡単で、プロジェクト ログでデバッグを開き、ログが毎回新しい sqlsession を作成しているかどうかを確認します。 mybatis セッションはプールされておらず、メソッド内で競合する SQL が出現した場合、エラーは発生しませんが、データベースは SQL を実行しません。すぐに、接続プールがすぐに使用され、新しい接続が頻繁に作成されることがわかります。もちろん、mybatis なしでできる場合は、ためらうことなく、使用しないのが正しいです。

なぜ静的アノテーションを使用する必要があるのでしょうか? それは非常に単純です。プロジェクトが十分に大きい場合、これらのシングルトンは何を占有するのでしょうか。オブジェクト インスタンスはヒープ領域にあり、参照はスタックにあります。それでは、GC はいつこれらのシングルトン オブジェクトをリサイクルするのでしょうか?あなたが思うこと？したがって、アノテーションに基づく場合は、動的プロキシの使用を減らすようにしてください。必要な場所に、より多くのリソースを残しておきます。

昔はヒープのないスタックなしと言っていましたが、現在はjdk1.7の文字列定数プールがヒープに置かれるようになりました。

コンパイルと解釈ではどちらが優れていますか? もちろん分析的ですが、コンパイルは中間モデルに似ています。したがって、優れたコンパイル言語を構築することは、インタプリタ言語よりもはるかに困難です。

Web の構造は非常に明確です。まず、コンテキストがあり、次に一連のコンポーネントが順番にあります。これは Javaee の標準です。コンポーネントはプロトコル標準であり、誰もが持つ必要があります。そうすると、多くのプロジェクトのサーブレット マッピングが / であることがわかります。これは非常に単純なので、js や css をサーブレット経由で処理する必要がないため、マッピングでは主にサーバーとの対話が考慮されます。 Webコンテナの-側コンポーネント 通常、.doと.actionの2種類の識別があり、.doは権限認証が必要で、アクションは直接解放されます。 js などはサーブレットに入る必要がなく、Web コンテキストは URL に従って直接返され、MVC での MVC インターセプトとリリースは不要であり、問​​題が発生し、問題を解決する良い方法ではありません。問題。このように、nginx の介入に関係なく、静的リソースは Web コンテナに対して静的であり、サーブレットとの関係はありません。サーブレットは、処理する必要があるものだけを扱います。

jsを書くのに最適な場所はどこですか?

多くの人は js を jsp または html で書くことに慣れていますが、それは良くありません。

プロジェクトを構築するときは、js と css がブラウザーによってキャッシュされることを期待する必要があります。

ページの script タグに書かれた js は単なるタグであり、div や input と何ら変わりはなく、キャッシュされません。多くの情報を確認したところ、キャッシュには の単位が明記されていました。キャッシュはファイルです。ラベルの代わりに。したがって、ファイルにCSS JSを記述し、ファイルがキャッシュされるようにファイルをインポートします。これは私の推測にすぎないため、完全にはわかりません。

jsp は実際にはサーブレットなので、動的翻訳のためにクラスをロードする必要があるたびに、クラス内の write メソッドがページをブラウザに書き込み、ブラウザがそれをレンダリングします。それは HTML であり、静的です。サーブレットなので、Java オブジェクトであり、さまざまな Java タグやメソッドが可能であることは間違いありません。静的ページは同様のマクロ言語を使用するため、直接 JSP を使用することをお勧めします。

一度にページに読み込む必要があるデータの量はどれくらいですか?

ページにカテゴリやリストに従って表示されている場合、データの量は非常に少なく、数百のアイテムで、種類は現在のテイクアウト注文アプリに表示されており、すべてのカテゴリとデータが一度に与えられるため、処理はエンド側の処理、カテゴリー切り替え、プレビューなど全プロセスは検索も含め全てページ上で処理されます、A社の携帯電話やパソコンで実行されるJSはB社の携帯電話やパソコンと競合しません。毎回タイプを切り替えるには、ajax を使用するだけです。これらはすべて同じ Web コンテナー グループに属しているため、競合が発生します。操作の頻度が高くなるほど、競争は激しくなります。この点は実際の現場と密接に関係しています。

クエリによって返されるデータの量は、パフォーマンスとはほとんど関係ありません。数千、数万のデータはわずか数十 KB です。

クエリの数、つまりサーバーとの対話の数は、全体的なパフォーマンスの直接の原因です。

クエリ内のデータの量は、クエリ対象のテーブルのサイズに比例します。一度に 10 個のアイテムを返してもクエリは高速化されません。また、一度に 1,000 個のアイテムを返してもデータベースの操作は遅くなりません。は本質的にコレクション アプリケーションであり、何も作成されません。

最適な量を与えることがチューニングの前提ですが、与えれば与えるほど適切になるというわけではありません。桁が違う。

必要に応じてキャッシュを使用します。

データベースまたはマスター/スレーブの分離など、現在のデータベースではビジネスをサポートできない必要があります。音量。

単一のケースが最良の方法です。

特定の言語に関係なく、マルチスレッドは鋭い剣です。

Maven 管理は良い方法ですが、暇でない限り、Maven プロジェクトを構築してから Web プロジェクトに変換するのではなく、Web プロジェクトを作成して Maven をコンポーネントとして埋め込む必要があります。

バネを使って、現状最高の足場です。

可能であれば、できるだけ jdbc を使用してください。

クライアントで何かを実行できる場合は、サーバーと対話しないでください。クライアントのリソースは膨大ですが、サーバーのリソースは限られています。

リアルタイム アプリケーションでない限り、送信するリクエストの数が少ないコードが良いコードです。

コード内のすべてのツールはツールであり、API は最も理解する必要があるものであり、どれが優れていてどれがそうでないかについての正確な答えはありません。

すべてはオブジェクトであり、Java にとっては純粋です。プロキシはオブジェクト、リフレクションはオブジェクト、オブジェクトはオブジェクトですが、基本的なデータ型はオブジェクトではありません。

基本的なタイプを除いて、プロセスがどれほど複雑であっても、対応するオブジェクトのメソッドとそのメソッドのパラメーターを組み合わせて実行されます。クラスをシリアル化および逆シリアル化する方法。端的に言えば、ファイルの IO と送信、そしてそれらを jvm にロードしてオブジェクトに構築することです。

rpcrpc がスレッド内で何かを呼び出しているのではなく、呼び出されているものがプロキシされる理由は、プロキシがユーザーのニーズをパラメーターに変換し、それらをデータ ストリームとして送信するためです。サーバーは、ユーザーのリクエスト ストリームをオブジェクトに変換します。ストリーミングされて送り返された後、オブジェクトを構築し、オブジェクトを通じてそれを処理します。

NIO は良い方法であり、netty は良い選択です netty を超えるマルチスレッドソケットはありますか?

zookeeper は、優れた分散登録などの一連のソリューションに最適なツールです。

これらは原則とオブジェクトなので、使用するにはよく調べなければなりません。

上記は私の個人的な理解ですので、修正は歓迎です。

JAVAEE プロジェクトの構造と同時実行性の考え方に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。