集める！春がマスターしなければならないこと-mysql チュートリアル-php.cn

mysqltutorial コラムでは、Spring についてマスターしなければならないことを紹介します。＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃こんにちは、みんな！私は熱心な朝陽族の一員です。

Spring フレームワークは面接で必ず聞かれる質問ですが、具体的にはどのような内容が含まれているのでしょうか?見てみましょう。これは私が面接でよく尋ねる質問でもあり、プログラマーのフレームワークに対する理解力を反映するものでもあります。

Spring フレームワークの紹介

一般に Spring Framework と呼ばれるものは、多くのモジュールを集めたものであり、これらのモジュールを使用すると、開発を簡単に支援できます。これらのモジュールは、コアコンテナー、データアクセス/統合、Web、AOP (アスペクト指向プログラミング)、ツール、メッセージング、およびテストモジュールです。たとえば、Core Container の Core コンポーネントはすべての Spring コンポーネントの中核であり、Beans コンポーネントと Context コンポーネントは IOC と DI を実装するための基礎であり、AOP コンポーネントはアスペクト指向プログラミングを実装するために使用されます。 Spring の 6 つの機能:

コアテクノロジ: 依存性注入 (DI)、AOP、イベント、リソース、i18n、検証、データバインディング、型変換、SpEL;

テスト:モックオブジェクト、TestContext フレームワーク、Spring MVC テスト、WebTestClient;

データアクセス: トランザクション、DAO サポート、JDBC、ORM、マーシャリング XML;

Web サポート: Spring MVC および Spring WebFlux Web フレームワーク;

統合: リモート処理、JMS、JCA、JMX、電子メール、タスク、スケジューリング、キャッシュ;

言語: Kotlin、Groovy、動的言語;

#いくつかの重要な Spring モジュールのリスト

下の図は Spring 4.x バージョンに対応しています。最新の 5.x バージョンの Web モジュールのポートレットコンポーネントは廃止され、非同期リアクティブ処理用の WebFlux コンポーネントが追加されました。

Spring Core: 基本的に、Spring の他のすべての機能はこのクラスライブラリに依存していると言えます。主にIOCおよびDI機能を提供します。
Spring Aspects: このモジュールは、AspectJ との統合のサポートを提供します。
Spring AOP: アスペクト指向プログラミングの実装を提供します。
Spring JDBC: Java データベース接続。
Spring JMS: Java メッセージサービス。
Spring ORM: Hibernate などの ORM ツールをサポートするために使用されます。
Spring Web: Web アプリケーションの作成のサポートを提供します。
Spring Test: JUnit および TestNG テストのサポートを提供します。

#Spring IOC と AOP についての理解を話してください

IOC

IOC (Inversion Of Controll、制御の反転) は設計上のアイデアです。プログラム内で手動で作成されたオブジェクトの制御は Spring フレームワークに渡されます。 IOC は他の言語でも使用されており、Spring に固有のものではありません。 IOCコンテナはSpringがIOCを実装するために使用するキャリアであり、実際にはMap(キー、値)であり、Map内に様々なオブジェクトが格納されます。

オブジェクト間の相互依存関係を IOC コンテナによって管理されるようにすると、IOC コンテナはオブジェクトの挿入を完了します。これにより、アプリケーション開発が大幅に簡素化され、アプリケーションを複雑な依存関係から解放できます。 IOC コンテナは工場のようなもので、オブジェクトを作成する必要がある場合、オブジェクトがどのように作成されるかを考えずに、設定ファイルやアノテーションを設定するだけで済みます。実際のプロジェクトでは、Service クラスの最下位層として数百、さらには数千のクラスが存在する場合があります。この Service をインスタンス化する必要がある場合、毎回、この Service の基になるすべてのクラスのコンストラクターを把握する必要があり、混乱する可能性があります。人々は気が狂いそうになる。 IOC を使用する場合、IOC を設定して必要な箇所で参照するだけで済むため、プロジェクトの保守性が大幅に向上し、開発の難易度が軽減されます。

Spring の時代には、XML ファイルを使用して Bean を設定するのが一般的でしたが、その後、開発者は XML ファイルを使用して Bean を設定するのはよくないと感じたため、Spring Boot アノテーション設定が徐々に普及してきました。

AOP

AOP（アスペクト指向プログラミング、アスペクト指向プログラミング） ) システム内のコードの重複を減らすために、ビジネスとは関係がないがビジネスモジュールによって一般的に呼び出されるロジックや責任 (トランザクション処理、ログ管理、権限制御など) をカプセル化できます。、モジュール間の結合を軽減し、将来の拡張性と保守性に貢献します。

Spring AOP はダイナミックプロキシに基づいています。プロキシされるオブジェクトが特定のインターフェイスを実装している場合、Spring AOP は JDK ダイナミックプロキシを使用してプロキシオブジェクトを作成しますが、インターフェイスを実装していないオブジェクトの場合は、 JDK ダイナミックプロキシは、代わりに CGlib ダイナミックプロキシを使用して、プロキシオブジェクトのサブクラスをプロキシとして生成します。

もちろん、AspectJ を使用することもできます。Spring AOP には AspectJ が統合されています。AspectJ は、Java エコシステムで最も完全な AOP フレームワークと見なされるべきです。 AOP を使用すると、いくつかの一般的な関数を抽象化し、必要な場所で直接使用できるため、コードの量を大幅に簡素化できます。新しい機能を便利に追加し、システムの拡張性を向上させる必要があります。 AOP は、ログ機能、トランザクション管理、権限管理などのシナリオで使用されます。

Spring AOP と AspectJ AOP の違い

Spring AOP はランタイム拡張機能です。、AspectJ はコンパイル時の機能強化です。 Spring AOP はプロキシ処理に基づいていますが、AspectJ はバイトコード操作に基づいています。

Spring AOP には AspectJ が統合されており、これは Java エコシステムで最も完全な AOP フレームワークとみなされます。 AspectJ は Spring AOP より強力ですが、Spring AOP は比較的単純です。

アスペクトの数が少ない場合、2 つの間のパフォーマンスの差はほとんどありません。ただし、アスペクトが多すぎる場合は、SpringAOP よりもはるかに高速な AspectJ を選択するのが最善です。

Spring の Bean のスコープは何ですか?

singleton: 唯一の Bean インスタンス。Spring の Bean はデフォルトですべてシングルトンです。
プロトタイプ: リクエストごとに新しい Bean インスタンスが作成されます。
request: 各 HTTP リクエストは、現在の HTTP リクエスト内でのみ有効な新しい Bean を生成します。
session: 各 HTTP リクエストは、現在の HTTP セッション内でのみ有効な新しい Bean を生成します。
global-session: グローバルセッションスコープはポートレットベースの Web アプリケーションでのみ意味があり、Spring 5 では使用できなくなりました。ポートレットは、セマンティックコード (HTML など) のスニペットを生成できる小さな Java Web プラグインです。これらはポートレットコンテナに基づいており、サーブレットのように HTTP リクエストを処理できます。ただし、サーブレットとは異なり、各ポートレットには異なるセッションがあります。

Spring のシングルトン Bean のスレッドセーフティの問題を理解していますか?

ほとんどの場合、システムでマルチスレッドを使用しないため、この問題に注目する人はほとんどいません。シングルトン Bean にはスレッドの問題があります。主な理由は、複数のスレッドが同じオブジェクトを操作する場合、このオブジェクトの非静的メンバー変数に操作を書き込むとスレッドの安全性の問題が発生するためです。

一般的な解決策は 2 つあります。

Bean オブジェクト内で可変メンバー変数を定義するのは避けてください (あまり現実的ではありません)。
クラスで ThreadLocal メンバー変数を定義し、必要な変数メンバー変数を ThreadLocal に保存します (推奨される方法)。

Spring の Bean のライフサイクル?

Bean コンテナは、構成ファイル内で Spring Bean の定義を見つけます。
Bean コンテナは Java Reflection API を使用して Bean インスタンスを作成します。
いくつかの属性値が関係する場合は、set() メソッドを使用していくつかの属性値を設定します。
Bean が BeanNameAware インターフェースを実装している場合は、setBeanName() メソッドを呼び出して Bean の名前を渡します。
Bean が BeanClassLoaderAware インターフェースを実装している場合は、setBeanClassLoader() メソッドを呼び出して、ClassLoader オブジェクトのインスタンスを渡します。
Bean が BeanFactoryAware インターフェースを実装している場合は、setBeanClassFacotory() メソッドを呼び出して、ClassLoader オブジェクトのインスタンスを渡します。
上記と同様、他の *Aware インターフェイスが実装されている場合は、対応するメソッドが呼び出されます。
このBeanをロードするSpringコンテナに関連するBeanPostProcessorオブジェクトが存在する場合は、postProcessBeforeInitialization()メソッドを実行します。
Bean が InitializingBean インターフェースを実装している場合は、afterPropertiesSet() メソッドを実行します。
設定ファイルのBean定義にinit-method属性が含まれている場合、指定されたメソッドを実行します。
このBeanをロードするSpringコンテナに関連するBeanPostProcessオブジェクトが存在する場合は、postProcessAfterInitialization()メソッドを実行します。
Bean を破棄する場合、Bean が DisposableBean インターフェースを実装している場合は、destroy() メソッドを実行します。
Bean を破棄する場合、設定ファイルの Bean の定義に destroy-method 属性が含まれている場合は、指定されたメソッドを実行します。

# Spring MVC についてのあなたの理解について教えてください。

この問題について話すと、Spring MVC のない以前の Model1 と Model2 の時代について触れなければなりません。

**Model1 時代:** Java を学んだのが遅いバックエンドプログラマの多くは、Model1 モードでの JavaWeb アプリケーション開発に慣れていない可能性があります。 Model1 モードでは、Web アプリケーション全体がほぼすべて JSP ページで構成され、データベース接続、アクセス、その他の操作の処理に少数の JavaBeans のみが使用されます。このモードでは、JSP はコントロール層とプレゼンテーション層の両方になります。明らかに、このモデルには多くの問題があります。例えば、制御ロジックと性能ロジックが混在してコードの再利用率が極端に低かったり、フロントエンドとバックエンドが相互に依存しているためテストが困難で開発効率が非常に低かったりするなどです。

モデル 2 時代 : サーブレットを研究し、関連デモを行ったことのある友人は、Java Bean (モデル) JSP (ビュー) サーブレット (コントローラー) の開発モデルを理解しているはずです。これは初期の Java Web です。 MVC開発モデル。モデルはシステムに関係するデータ、つまり dao と Bean です。ビューはモデル内のデータを表示するために使用されます (表示のみ)。コントローラーはユーザーのリクエストを処理のためにサーブレットに送信し、データを JSP に返して表示します。ユーザー。

Model2 モードにはまだ多くの問題があります。Model2 の抽象化とカプセル化の度合いは十分とは言えません。開発に Model2 を使用する場合、車輪の再発明が避けられず、保守性と使いやすさが大幅に低下します。プログラムの再利用性。その結果、Struts2 など Java Web 開発に関連する MVC フレームワークが数多く誕生しましたが、Struts2 は比較的扱いにくいため、Spring の軽量開発フレームワークの人気に伴い、Spring MVC フレームワークが Spring エコシステムに登場しました。 Spring MVC は現在最高の MVC フレームワークであり、Struts2 に比べてシンプルで使いやすく、開発効率が高く、動作も高速です。

MVC はデザインパターンであり、Spring MVC は優れた MVC フレームワークです。 Spring MVC は、より簡潔な Web 層の開発に役立ち、Spring フレームワークと自然に統合されています。 Spring MVCでは通常、バックエンドプロジェクトをサービス層（処理ビジネス）、Dao層（データベース操作）、エンティティ層（エンティティクラス）、コントローラー層（データをフロントエンドページに返す制御層）に分割します。

Spring MVC の簡単な概略図は次のとおりです。

Spring MVC の動作原理について話します

##プロセスの説明:

1. クライアント (ブラウザ) は、リクエストを DispatcherServlet に直接送信します。

2.DispatcherServlet は、リクエスト情報に基づいて HandlerMapping を呼び出し、リクエストに対応する Handler を解析します。

3. 対応するハンドラー (通常コントローラーと呼ばれるもの) に解析します。

4.HandlerAdapter は、Handler に従って実際のプロセッサを呼び出し、リクエストを処理し、対応するビジネスロジックを実行します。

5. プロセッサがビジネスの処理を完了すると、ModelAndView オブジェクトが返されます。Model は返されたデータオブジェクトで、View は論理ビューです。

6.ViewResolver は、論理ビューに基づいて実際のビューを見つけます。

7.DispatcherServlet は、返されたモデルを View に渡します (ビューのレンダリング)。

8. ビューを要求者 (ブラウザー) に返します。

##Spring フレームワークではどのようなデザインパターンが使用されていますか?

ファクトリ設計パターン: Spring はファクトリパターンを使用して、BeanFactory および ApplicationContext を通じて Bean オブジェクトを作成します。
プロキシ設計パターン: Spring AOP 機能の実装。
シングルケース設計パターン: Spring の Bean はデフォルトでシングルトンです。
テンプレートメソッドパターン: jdbcTemplate、hibernateTemplate、およびデータベース上で動作する Spring の Template で終わるその他のクラスは、テンプレートパターンを使用します。
ラッパー設計パターン: 私たちのプロジェクトは複数のデータベースに接続する必要があり、さまざまな顧客が訪問するたびにニーズに応じてさまざまなデータベースにアクセスします。このモデルにより、顧客のニーズに応じて異なるデータソースを動的に切り替えることができます。
オブザーバーパターン: Spring イベント駆動モデルは、オブザーバーパターンの古典的なアプリケーションです。
アダプターモード: Spring AOP の拡張機能またはアドバイス (アドバイス) はアダプターモードを使用し、Spring MVC もコントローラーを適応させるためにアダプターモードを使用します。

#@Component と @Bean の違いは何ですか?

行動の対象が異なります。 @Component アノテーションはクラスに作用し、@Bean アノテーションはメソッドに作用します。
@コンポーネントアノテーションは通常、自動的に検出され、クラスパススキャンを通じて Spring コンテナに自動的に組み込まれます (@ComponentScan アノテーションを使用して、スキャンするパスを定義できます)。 @Bean アノテーションは通常、この Bean を生成するためのアノテーションが付けられたメソッド内で定義され、これが特定のクラスのインスタンスであり、使用する必要があるときに返されることを Spring に伝えます。
@Bean アノテーションは @Component アノテーションよりもカスタマイズ可能であり、多くの場合、Bean は @Bean アノテーションを介してのみ登録できます。たとえば、サードパーティのライブラリを参照するクラスを Spring コンテナにアセンブルする必要がある場合、これは @Bean アノテーションを介してのみ実現できます。

@Bean アノテーションの使用例:

@Configurationpublic class AppConfig {    @Bean    public TransferService transferService() {        return new TransferServiceImpl();    }}复制代码

ログイン後にコピー

上記のコードは、次の XML 構成と同等です:

<beans>    <bean id="transferService" class="com.common.TransferServiceImpl"/></beans>复制代码

ログイン後にコピー

次の例は渡せません@コンポーネントのアノテーションによって実装:

@Beanpublic OneService getService(status) {    case (status)  {        when 1:                return new serviceImpl1();        when 2:                return new serviceImpl2();        when 3:                return new serviceImpl3();    }}复制代码

ログイン後にコピー

将一个类声明为Spring的bean的注解有哪些？

我们一般使用@Autowired注解去自动装配bean。而想要把一个类标识为可以用@Autowired注解自动装配的bean，可以采用以下的注解实现：

@Component注解。通用的注解，可标注任意类为Spring组件。如果一个Bean不知道属于哪一个层，可以使用@Component注解标注。
@Repository注解。对应持久层，即Dao层，主要用于数据库相关操作。
@Service注解。对应服务层，即Service层，主要涉及一些复杂的逻辑，需要用到Dao层（注入）。
@Controller注解。对应Spring MVC的控制层，即Controller层，主要用于接受用户请求并调用Service层的方法返回数据给前端页面。

Spring事务管理的方式有几种？

编程式事务：在代码中硬编码（不推荐使用）。
声明式事务：在配置文件中配置（推荐使用），分为基于XML的声明式事务和基于注解的声明式事务。

Spring事务中的隔离级别有哪几种？

在TransactionDefinition接口中定义了五个表示隔离级别的常量：

**ISOLATION_DEFAULT：**使用后端数据库默认的隔离级别，Mysql默认采用的REPEATABLE_READ隔离级别；Oracle默认采用的READ_COMMITTED隔离级别。

**ISOLATION_READ_UNCOMMITTED：**最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。

**ISOLATION_READ_COMMITTED: **同時トランザクションによって送信されたデータの読み取りを許可します。これによりダーティリードを防ぐことができますが、ファントムリードや反復不可能な読み取りが発生する可能性があります。

**ISOLATION_REPEATABLE_READ:**同じフィールドの場合、データが独自のトランザクション自体によって変更されない限り、複数の読み取りの結果は一貫しています。これにより、ダーティリードや反復不可能な読み取りを防ぐことができますが、ファントムリードが発生する可能性はあります。

**ISOLATION_SERIALIZABLE: **ACID 分離レベルに完全に準拠した最高の分離レベル。すべてのトランザクションは順番に実行されるため、トランザクション間で干渉する可能性がなく、ダーティリード、ノンリピートリード、ファントムリードを防ぐことができます。しかし、これはプログラムのパフォーマンスに重大な影響を与えます。通常、このレベルは使用されません。