Skip to content

Lazily allocate HashMap in PathMatchingHttpServletRequestWrapper#11142

Closed
dougqh wants to merge 1 commit intomasterfrom
dougqh/optimize-variable-merging
Closed

Lazily allocate HashMap in PathMatchingHttpServletRequestWrapper#11142
dougqh wants to merge 1 commit intomasterfrom
dougqh/optimize-variable-merging

Conversation

@dougqh
Copy link
Copy Markdown
Contributor

@dougqh dougqh commented Apr 16, 2026

Summary

  • Makes the localAttributes HashMap in PathMatchingHttpServletRequestWrapper lazily initialized — only allocated on first setAttribute() call
  • For requests that don't match any handler mapping, Spring's getHandler() returns null without calling setAttribute, so the HashMap is never allocated
  • Applied to both 3.1 and 6.0 wrapper implementations

Motivation: HandlerMappingResourceNameFilter creates a PathMatchingHttpServletRequestWrapper (with an internal HashMap + 16-entry Node[] array) on every request before checking if a matching handler exists. For non-matching requests, the allocation is wasted.

Files changed

  • PathMatchingHttpServletRequestWrapper.java (3.1) — lazy init
  • PathMatchingHttpServletRequestWrapper.java (6.0) — lazy init

Test plan

  • All spring-webmvc-3.1 tests pass (including forked)
  • All spring-webmvc-5.3 tests pass
  • All spring-webmvc-6.0 tests pass
  • Run full CI suite

tag: no release note
tag: ai generated

🤖 Generated with Claude Code

The wrapper is created on every request to isolate attribute side effects
during handler mapping lookups. Previously, a HashMap was eagerly allocated
even when no handler mapping matched (and thus no attributes were set).
This defers the HashMap allocation to the first setAttribute call, avoiding
the cost of a HashMap with its 16-entry Node array on requests that don't
match any handler mapping.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@dougqh dougqh closed this Apr 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant