Recently transferred from PHP to Java. But it always confuses a problem. Is why Java has the concept of connection pooling?
PHP is run from the beginning of the script to the end of the script, the end of the script, the object is not automatically. How does Java work? Is Java a different thread called or the same object, it is not messy?? Different users come, how to distinguish who is the object of who?? I got dizzy. Now I dare not new object.
Reply content:
Recently transferred from PHP to Java. But it always confuses a problem. Is why Java has the concept of connection pooling?
PHP is run from the beginning of the script to the end of the script, the end of the script, the object is not automatically. How does Java work? Is Java a different thread called or the same object, it is not messy?? Different users come, how to distinguish who is the object of who?? I got dizzy. Now I dare not new object.
PHP and Java have done, to help the building manager.
Doubt and speculation: the landlord is to use PHP and Java to do the web.
Of course, that's not important, but if it's all about the web, it could be confusing at first because of the differences between the process and the thread.
First of all, the Java operation, starting from the main method as the portal, starts a JVM process.
1, if the landlord just run a simple java script, as in other languages, is the main method run-end, objects are destroyed.
2, if it is to run a web, then I use Tomcat+servlet way to explain and php+cgi is not the same:
(1) for a Web program (with Tomcat), the Java runtime starts with a JVM that starts with Tomcat, and this is when a process is running and all objects are in the process.
(2) When an HTTP request comes in, Tomcat has a dedicated object that will create a thread to load the corresponding servlet or JSP page (which is similar to PHP) and then execute and respond after the request is received.
The difference is here, PHP through webserver+cgi is to start a process to execute PHP script until the end of the run, then the request is not any object or.
But Java, because Tomcat has not been shut down, so the whole process is always alive. You access a JSP, if it has global variables, then even if the JSP script finishes executing the response, the global variable will remain in the JVM memory that the Tomcat initiates.
Do not know the landlord can see clearly not.
"Is Java a different thread called or the same object, that's not a mess?" ”
About this question. As I mentioned above, the special object is the same. It receives a request and then assigns a thread to each request to process.
In the case of concurrency, this object can be used by multiple threads at the same time. So why can it be the same object processing, is thread-safe this piece, this you can see @ fabricated faith solution, written very clearly, but you want to understand multithreading.
I'm only explaining things about multithreading. First, the landlord may need to understand, in Java, what kind of object can be shared by multiple threads, what kind of object is not possible . This criterion depends on whether the members of the object can be shared between threads. Like what
public class A { public int value;}
Obviously, if multiple threads access the same a object at the same time, it can be dangerous because they will "mess up" the value. The class A is also known as non-thread-safe. But if I change to this:
public class A { private int value; // 1 public A(int value) {this.value = value;} // 2 public int getValue() {return this.value;} // 3}
So a becomes thread-safe, for what, because its member value becomes private at (1), and can only be assigned in the constructor (2), and once the assignment is only read (3), and the read can be done concurrently by multiple threads.
So, a simple rule is that an assignable member becomes a risk in multiple threads. If a class contains assignable members, the object of the class should exist independently of the thread, and should not be shared to multiple threads at the same time, unless only one thread is guaranteed to write.