Why does Java have much better performance compared to other interpreted languages like Python? I know this probably has something to do with the fact that it's compiled beforehand, but what about concurrency?

How is the JVM able to perform so much better with concurrent programs, whereas interpreted languages have to do deal with things like global interpreter locking etc, that really slow things down?

解决方案

This is a really interesting question, but I'm not sure there's a simple way to answer it. JVMs these days use a range of highly aggressive optimizations to try to improve performance. Here are a few:

Dynamic compilation: Most good JVMs can dynamically compile the bytecode directly into machine code, which then executes at native speeds.

Polymorphic inline caching: Many JVMs use inline caching to try to improve the performance of method dispatching by remembering which functions have been called in the past.

Static typing: Since Java is statically-typed, bytecode instructions rarely have to do expensive introspection on the type of an object to determine how to perform an operation on it. Field offsets can be computed statically, and method indices in a virtual function table can be precomputed as well. Contrast this with languages like JavaScript, which don't have static typing and are much harder to interpret.

Garbage collection: The JVM garbage collector is optimized to allocate and deallocate objects efficiently. It uses a combination of mark-and-sweep and stop-and-copy techniques to make most allocations really fast and to make it easy to reclaim lots of memory quickly.

Known choke points: Rather than having a huge VM lock, some JVM implementations automatically insert extra code into each piece of compiled/interpreted code to periodically check in with the VM and determine whether they can keep running. That way, if the JVM needs to do garbage collection in only a few threads, it can do so while the other threads are running. If it needs to do a stop-the-world operation, it will only occur when the threads hit specific points, meaning that simple operations don't have to continuously check in with the VM state.

There are many, many more optimizations in place that I'm probably not aware of, but I hope that this helps you get toward an answer!