第1章 Spring Framework 概览
版本：5.1.3.RELEASE
Spring使创建Java企业应用程序变得容易。它提供了在企业环境中使用Java语言所需的一切，支持Groovy和Kotlin(Java是基于JVM的语言,Groovy和Kotlin也是一门基于JVM的语言)，并有灵活地根据应用程序的需求创建多种类型的体系架构。
从SpringFramework5.0开始，Spring需要JDK8+（JAVA SE8+），并且已经为JDK9提供了开箱即用的支持。
Spring支持广泛的应用场景。在大型企业中，应用程序通常存在很长时间，必须运行在JDK和应用程序服务器上，其升级周期超出了开发人员的控制。其他的可以作为单个jar运行，并嵌入服务器，可能在云环境中。然而，其他应用程序可能是不需要服务器的独立应用程序（如批处理或集成工作负载）
Spring 是开源的。它有一个庞大而活跃的社区，基于真实的使用场景提供连续的反馈。这有助于Spring在很长一段时间内成功地发展。
1.1 我们所说的“Spring”是什么意思
“Spring”一词在不同的语境中有着不同的含义。它曾经指的是Spring Framework 项目本身。随着时间的推移，Spring的其他子项目已经构建在Spring框架的基础之上。大多数情况下，人们说的Spring,是指的整个Spring 项目家族。当前这个文档主要讲解Spring Framework 本身。
Spring Framework 被分割成了很多模块。应用程序可以选择他们需要的模块。
Spring框架分为多个模块。应用程序可以选择他们需要的模块。核心容器是所有模块的心脏，包括配置模型和依赖注入机制。除此之外，Spring Framework
框架为不同的应用程序体系架构提供基础支持，包括消息传递、事务数据和持久性以及Web。它还包括基于servlet的SpringMVC Web框架，以及并行的SpringWebFlux Reactive(反应式)Web框架。
当然，Spring Framework 可以在JDK 8 和JDK 9 正常工作
1.2 Spring Framework 发展历史
作为对早期J2EE规范复杂性的回应，Spring于2003年诞生。虽然有些人认为JavaEE和Spring处于竞争中，但实际上，Spring与JavaEE是互补的。Spring编程模型不接受JavaEE平台规范，而是集成了来自EE的精心选择的个别规范。
Servlet API (JSR 340–>Java Servlet 3.1规范)
WebSocket API (JSR 356–>用于WebSocket的Java TM API)
Concurrency Utilities (JSR 236–>Java TM EE的并发实用程序)
JSON Binding API (JSR 367–>用于JSON绑定的Java TM API（JSON-B）)
Bean Validation (JSR 303–>Bean验证)
JPA (JSR 338–>Java TM Persistence 2.2)
JMS (JSR 914–>Java TM消息服务（JMS）API)
以及必要时用于事务协调的JTA / JCA设置。
Spring Framework 也支持依赖注入(JSR 330)和注解(JSR 250)
应用程序开发人员可以选择使用这些规范，而不是Spring框架提供的特定于Spring的机制。
对于Spring FrameWork 5，Spring需要JavaEE 7 Level（例如servlet 3.1 +，JPA 2.1+）作为最小值，同时在运行时遇到的Java EE 8级（例如servlet 4.0、JSON绑定API）提供开箱即用与新版Apls集成。这使Spring与Tomcat8和9、WebSphere9和JBoss EAP7完全兼容。
随着时间的推移，Java EE在应用程序开发中的作用也在不断发展。 在Java EE和Spring的早期，创建了应用程序以部署到应用程序服务器。 今天，在Spring Boot的帮助下，应用程序以devops和cloud-friendly的方式创建，Servlet容器嵌入并且变得微不足道。 从Spring Framework 5开始，WebFlux应用程序甚至不直接使用Servlet API，并且可以在不是Servlet容器的服务器（例如Netty）上运行。
Spring不断创新，不断超越Spring框架，还有其他项目，如Spring BootSecurity, Spring Data, Spring Cloud, Spring Batch等等。
必须记住，每个项目都有自己的源代码存储库、问题跟踪程序和发布节奏。看 spring.io/projects 项目完整清单的项目。
1.3 设计理念
当您了解框架时，重要的是不仅要知道它的作用，还要了解它遵循的原则。以下是Spring Framework的指导原则：
-
提供各个层面的选择。Spring允许您尽可能晚地推迟设计决策。例如，您可以通过配置切换持久性提供程序，而无需更改代码。许多其他基础架构问题以及与第三方API的集成也是如此。
-
适应不同的观点。Spring拥抱灵活性，并不认为应该如何做。它以不同的视角支持广泛的应用需求。
-
保持强大的向后兼容性。Spring的演变经过精心设计，可以在版本之间进行一些重大改变。Spring支持精心挑选的JDK版本和第三方库，以便于维护依赖于Spring的应用程序和库。
-
关心API设计。Spring团队投入了大量的思考和时间来制作直观的API，并且可以支持多个版本和多年。
-
为代码质量设定高标准。Spring框架强调有意义的，当前的和准确的javadoc。它是极少数项目之一，可以声称干净的代码结构，包之间没有循环依赖。
1.4 反馈和贡献
对于操作方法问题或诊断或调试问题，我们建议使用StackOverflow，我们有一个问题页面列出了要使用的建议标签如果您非常确定Spring Framework中存在问题或想要建议功能，请使用JIRA问题跟踪器。
如果您有解决方案或建议的修复，您可以在Github上提交拉取请求 。但是，请记住，除了最微不足道的问题之外，我们希望在问题跟踪器中提交一张票据，进行讨论并留下记录以供将来参考。
有关更多详细信息，请参阅“ 贡献 ”顶级项目页面上的指南。
1.5 入门
如果您刚刚开始使用Spring，您可能希望通过创建基于Spring Boot的应用程序来开始使用Spring Framework 。Spring Boot提供了一种快速（和固执己见）的方式来创建一个生产就绪的基于Spring的应用程序。它基于Spring Framework，支持约定优于配置，旨在帮助您尽快启动和运行。
您可以使用start.spring.io生成基本项目，也可以按照“入门”指南之一进行操作，例如“ 入门构建RESTful Web服务”。除了更容易理解之外，这些指南非常注重任务，而且大多数都基于Spring Boot。它们还涵盖了Spring组合中您在解决特定问题时可能需要考虑的其他项目。
1.6 JDK 版本范围
| Spring Framework版本 | JDK版本 |
|---|---|
| Spring Framework 5.1.x | JDK 8-12 |
| Spring Framework 5.0.x | JDK 8-10 |
| Spring Framework 4.3.x | JDK 6-8 |
1.7 升级说明
Upgrading to Spring Framework 5.0/5.1
升级到5.1版
JDK 11
Spring Framework 5.1需要JDK 8或更高版本，并且首次特别支持JDK 11（作为下一个长期支持版本）。对于任何面向JDK 11的应用程序，我们强烈建议升级到Spring Framework 5.1，在类路径和模块路径上提供无警告的体验。
请注意，任何旧版本的核心框架都不支持针对JDK 11进行开发。Spring Framework 5.0.9+和4.3.19+仅支持将基于Java 8的应用程序部署到JVM 11运行时环境（使用-target 1.8;参见下文），在启动时接受JVM级警告。
ASM
Spring Framework 5.1使用了为JDK 11/12准备的修补的ASM 7.0 fork及其新的字节码级别，但尚未经过实战测试。Spring Framework 5.1.x将跟踪JDK 12的进一步ASM修订，同时加强与JDK 11的字节码兼容性。
对于防御性升级策略，考虑使用JDK 8作为目标（-target 1.8）编译应用程序代码，只需将其部署到JDK 11.这使得您的字节码更安全，不仅可以解析Spring的类路径扫描，还可以解析其他字节码处理工具。
CGLIB
Spring Framework 5.1使用修补的CGLIB 3.2 fork，委托JDK 9+ API在运行时定义类。由于此代码路径仅在JDK 9或更高版本上实际运行时才会处于活动状态（特别是在已删除用于定义类的备用API的JDK 11上是必需的），因此在将现有应用程序升级到JDK 11时可能会出现副作用。
Spring有一个后备，它试图缓解类定义问题，可能导致记录JVM警告，而标准代码路径在JDK 11上提供无警告经验，用于常规类定义。考虑在这种情况下重新访问类定义和字节码处理工具，将它们升级到JDK 11策略。
核心容器
核心容器已针对Graal兼容性（基板VM上的本机映像）进行了微调，并且通常针对较少的启动开销和较少的垃圾收集压力进行了优化。作为这项工作的一部分，已经简化了几种内省算法，以避免不必要的反射步骤，可能会导致在明确定义的位置之外声明的注释产生副作用。
嵌套配置类检测
根据它们的原始定义，嵌套配置类现在只在顶级@Configuration或其他@Component原型类上检测到，而不是简单地使用@Import或@ComponentScan。较旧版本的Spring在非构造型类上过度内省嵌套类，在某些情况下会导致显着的启动开销。
如果在普通类上意外地依赖嵌套类检测，只需声明包含具有配置/组件构造型的类的那些。
Web应用程序
转发标题
“Forwarded”"X-Forwarded-*"反映客户原始地址的标题和标题不再在适用的地方单独检查，例如同源CORS检查MvcUriComponentsBuilder等。
应用有望使用的一种：
Spring Framework自己的ForwardedHeaderFilter。
支持来自HTTP服务器或代理的转发标头。
请注意，ForwardedHeaderFilter可以在安全模式下进行配置，在此模式下，它会检查并丢弃此类标头，以免影响应用程序。
编码模式 DefaultUriBuilderFactory
DefaultUriBuilderFactory已切换编码模式以默认强制执行更严格的URI变量编码。这可能会影响使用WebClient默认设置的任何应用程序，或任何DefaultUriBuilderFactory直接使用的应用程序。请参阅“编码URI”部分以及Javadoc for DefaultUriBuilderFactory#setEncodingMode。
错误响应的内容协商
生成条件@RequestMapping不再影响错误响应的内容类型。
多部分和查询值
现在，与Apache Commons FileUpload的集成可以根据Servlet规范3.1节的要求，将多部分参数值与查询中的其他请求参数进行聚合。以前它只返回多部分参数值（如果存在）。
HTTP选项
@RequestMapping现在，对方法中的HTTP OPTIONS的内置支持始终将HTTP OPTIONS添加为受支持的HTTP方法之一，而之前则没有。