Request processing in Java (or any other sane language) is Request-scoped.
The Request is a variable, the Response is a variable, they're only in local scope?
And any data the developer uses will also be local -- and thus stateless -- unless they go out of their way to share something. (Caches are a common example, but harder in PHP since nothing by default is shareable.)
You don't need to deal with threads if you're seeking PHP-equivalent functionality.
And if you did need to deal with threads, I find your claims about overheads & difficulty hard to read without a little skepticism. An idle thread is faster to start than spawning a process, an uncontended synchronization takes only 20-250 CPU cycles (ie. a modest number of nanoseconds), and a thread pool can be sensibly managed in 2-3 lines of code.
I think what the comment really means by "request scoped" is that the PHP process is totally torn down after each request. In Java you can mutate global state as its running. You can leak memory until you OOM.
One unfortunate side effect is PHP's choice to use the word "global" for what isn't really global but request scope. The "global variables are bad" folks look down on the PHP global scope just because of the name.
Tearing down the entire request after processing is (IMHO) a remarkable effective approach.
I don't know. I think that global variables, even in PHP, are still poor software engineering. It still, very much, makes the code harder to reason about and debug. In fact, my understanding of the anti-global-vars rhetoric is that it's very much about understanding and debugging.
Tbh, that's done in modern PHP frameworks as well. ReactPHP & Co rely on you not using global variables, Symfony's architecture is built for that as well. You don't want to incur the startup cost for every request, because it's very slow.
This doesn't matter a lot in single requests of course, but once you're writing APIs that get considerable traffic, you'll want to cut out those 50ms and the load.
The Request is a variable, the Response is a variable, they're only in local scope?
And any data the developer uses will also be local -- and thus stateless -- unless they go out of their way to share something. (Caches are a common example, but harder in PHP since nothing by default is shareable.)
You don't need to deal with threads if you're seeking PHP-equivalent functionality.
And if you did need to deal with threads, I find your claims about overheads & difficulty hard to read without a little skepticism. An idle thread is faster to start than spawning a process, an uncontended synchronization takes only 20-250 CPU cycles (ie. a modest number of nanoseconds), and a thread pool can be sensibly managed in 2-3 lines of code.