JSP Lifecycle — Number of In-Memory Instances How many copies (instances) of a given JSP page's generated servlet are typically kept in memory by the servlet container at one time under normal configuration?

Introduction:
JavaServer Pages (JSP) are compiled into servlets. Understanding the default instance model helps developers reason about concurrency, thread safety, and the correct use of instance variables versus request-scoped data.

Given Data / Assumptions:

• A JSP is translated into a servlet class by the container.
• By default, a single servlet instance handles many requests concurrently using multiple threads.
• Containers may create additional instances under special configurations, but that is not the default.

Concept / Approach:
The conventional servlet/JSP model is “one instance, many threads.” The container maintains one instance of the generated servlet and dispatches concurrent requests to it using separate threads. Therefore, developers must avoid storing per-request state in instance fields unless properly synchronized or avoided altogether.

Step-by-Step Solution:
1) Recall that JSPs become servlets managed by the container.2) Recognize the default singleton-like instance model for servlets/JSPs.3) Conclude that typically one instance is in memory for a given JSP.

Verification / Alternative check:
Servlet specifications describe concurrent handling via multiple threads per servlet instance, with SingleThreadModel deprecated long ago, reinforcing the one-instance default assumption.

Why Other Options Are Wrong:

• Two/Three/Unlimited: Not the default instance policy; scaling is via threads, not many instances.
• One per active session: Incorrect; sessions do not create separate servlet instances.

Common Pitfalls:
Using servlet/JSP instance fields for request data and causing race conditions in concurrent access.

Final Answer:
One