I created a rest service using Spring RestController. When multiple request comes to access this service, how many instances are created for my RestController class?
A. Single instance created(as spring beans are by default singleton) ans used by threads one by one
B. For each request a new instance created.
To quote one of the old clever programmers;
"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." [Donald Knuth].
Web applications are not "programs" in the sense of being independent free-running processes. Instead they function more like DLLs.
When a web request comes in, the appserver analyzes the request to determine its characteristics, which includes figuring out which of possibly several webapps are deployed in the system. The request itself appears as data structures, but they are all bound together and attached to a Thread pulled from the server's application Thread pool. This Thread then invokes the servlet (or compiled JSP) that corresponds to the request URL by calling its service() method, which often delegates to HttpServlet doGet, doPut, etc., and in the case of Spring, to Spring's own dispatcher servlet code.
So it's absolutely essential that all logic in the chain that handles web requests must be Thread-safe. And, as a reminder, the dispatched Threads themselves are forbidden by the JEE spec from spawning child Threads. So there's only one Thread per Request, but possibly many concurrent Requests.
Another potential, but usually not practical problem is when a request processor handles database operations. As long as the concurrent operations are working with data from distinct bean instances, good database transaction management will take care of the rest. Note that the master processor logic bean(s) can be singletons, it's just the data beans (which are often session- and/or request-scope objects) that need to be thread-safe.
This perhaps isn't be most lucid explanation I've ever made of what the concurrency aspects of web processing are, but I hope it helped.
One final note, however: the best way to get into serious trouble when processing web requests is to store member data in the logic beans. Since the logic beans may be used by multiple threads concurrently, that's begging for trouble. Keep the data out of the logic beans and use the safer session and request scopes for per-user data. Application scope is also not thread-safe, since it's essentially a singleton resource itself.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.