ce7278aaf4
Several benchmarks underlined a few hotspots for CPU and GC pressure in the Spring Framework codebase: 1. `org.springframework.util.MimeType.<init>(String, String, Map)` 2. `org.springframework.util.LinkedCaseInsensitiveMap.convertKey(String)` Both are linked with HTTP request headers parsing and response headers writin during the exchange processing phase. 1) is linked to repeated calls to `HttpHeaders.getContentType` within a single request handling. The media type parsing operation is expensive and the result doesn't change between calls, since the request headers are immutable at that point. This commit improves this by caching the parsed `MediaType` for the `"Content-Type"` request header in the `ReadOnlyHttpHeaders` class. This change is available for both Spring MVC and Spring WebFlux. 2) is linked to insertions/lookups in the `LinkedCaseInsensitiveMap`, which is the data structure behind `HttpHeaders`. Those operations are creating a lot of garbage (including a lot of `String` created by `toLowerCase`). We could choose a more efficient data structure for storing HTTP headers data. As a first step, this commit is focusing on Spring WebFlux and introduces `MultiValueMap` implementations mapped by native HTTP headers for the following servers: Tomcat, Jetty, Netty and Undertow. Such implementations avoid unnecessary copying of the headers and leverages as much as possible optimized operations provided by the native implementations. This change has a few consequences: * `HttpHeaders` can now wrap a `MultiValueMap` directly * The default constructor of `HttpHeaders` is still backed by a `LinkedCaseInsensitiveMap` * The HTTP request headers for the websocket HTTP handshake now need to be cloned, because native headers are likely to be pooled/recycled by the server implementation, hence gone when the initial HTTP exchange is done Issue: SPR-17250 |
||
|---|---|---|
| buildSrc | ||
| gradle | ||
| spring-aop | ||
| spring-aspects | ||
| spring-beans | ||
| spring-context | ||
| spring-context-indexer | ||
| spring-context-support | ||
| spring-core | ||
| spring-expression | ||
| spring-framework-bom | ||
| spring-instrument | ||
| spring-jcl | ||
| spring-jdbc | ||
| spring-jms | ||
| spring-messaging | ||
| spring-orm | ||
| spring-oxm | ||
| spring-test | ||
| spring-tx | ||
| spring-web | ||
| spring-webflux | ||
| spring-webmvc | ||
| spring-websocket | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .mailmap | ||
| CODE_OF_CONDUCT.adoc | ||
| CONTRIBUTING.md | ||
| README.md | ||
| build.gradle | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| import-into-eclipse.md | ||
| import-into-idea.md | ||
| settings.gradle | ||
README.md
Spring Framework
This is the home of the Spring Framework, the foundation for all Spring projects. Together the Spring Framework and the family of Spring projects make up what we call "Spring".
Spring provides everything you need beyond the Java language to create enterprise applications in a wide range of scenarios and architectures. Please read the Overview section in the reference for a more complete introduction.
Code of Conduct
This project is governed by the Spring Code of Conduct. By participating you are expected to uphold this code. Please report unacceptable behavior to spring-code-of-conduct@pivotal.io.
Access to Binaries
For access to artifacts or a distribution zip, see the Spring Framework Artifacts wiki page.
Documentation
The Spring Frameworks maintains reference documentation (published and source), Github wiki pages, and an API reference. There are also guides and tutorials across Spring projects.
Build from Source
See the Build from Source wiki page and also CONTRIBUTING.md.
Stay in Touch
Follow @SpringCentral, @SpringFramework, and its team members on Twitter. In-depth articles can be found at The Spring Blog, and releases are announced via our news feed.
License
The Spring Framework is released under version 2.0 of the Apache License.