Some of the basic problems due to work in the relatively small but is not small, so the answer will be slow, uncertain, inaccurate, hereby opened the article records encountered uncertainty or answer more difficult questions.
1.servlet is a single case, is it safe, multi-threaded?
The servlet is a singleton, and after one instantiation of the Web. XML, other accesses invoke the servlet instance in a multithreaded manner.
As a result, the security of multi-threaded access to shared variables is a cliché. As long as you know that the servlet is a singleton, other problems are solved. The way the servlet is implemented determines security. is the member variable static and locked? Is there a lock on the method that calls the member variable? Or is it using a local variable inside the wrapper thread?
2. What is thread safety? Is the commonly used hashmap,arraylist safe?
The focus of thread safety is still the problem of sharing variables, to understand the change of shared variables to understand the JMM (Java memory model), the simple is that the thread has a workspace, variables placed in the memory heap. The thread work must copy a copy to work in the workspace, which is called reading. Writes the result to memory after the thread has finished working. There are sequential issues when multiple threads read and write. The read/write disorder in the JVM makes the actual value of the variable uncertain, and the value of the variable that each thread gets is the time it is read, and the subsequent change in time does not affect the value that the thread knows, that is, the visibility issue. The workspaces for the threads in the JVM are not visible to each other. It is because thread reads and writes are carried out in two steps, and other actions that occur between them cause inaccuracies in the end result, which is the cause of insecurity: atomicity . Only ensure that the read and write operations are atomic to ensure the accuracy of variables, so is thread synchronization , that is, locked. You can use synchronized and lock, as well as volatile.
HashMap and ArrayList are not thread-safe. You can use and contract the CONCURRENTHASHMAP under concurrent, this class uses the segmented write lock to improve concurrency and ensure write security. Similarly, the copyonwritearraylist is locked by writing and creates a copy, and after the copy is written, the other threads are visible through the volatile rules and the cache is consistent so that the replicas in the other threads are invalidated.
3. Talk about the Java memory model
Java memory model,jmm.
Similar to the previous question, the main problem is the storage and assignment of variables. The volatile in the previous article has a description.
First, Java operations on variables: Read, calculate, assign are implemented in the thread, the variables are placed in the main memory (that is, memory), and the calculation must be placed in the thread's workspace (corresponding to the hardware is l1,l2 and register). The workspace between the threads is only held by the thread itself and cannot be accessed or seen by other threads. This is the encapsulation of JMM for visibility . The thread cannot guarantee the exact time to write to memory, which is " unordered write ", depending on the calculated time. Java is locked to ensure atomic operation, atomicity . Java allows the compiler and processor to reorder instructions, but the reordering process does not affect the execution of a single-threaded procedure, but it can affect the correctness of multithreaded concurrency execution. , the Java memory model has some innate " ordering ," which means that there is no need to be able to guarantee the order of anything, and this usually becomes the happens-before principle. If the order of execution of two operations cannot be deduced from the happens-before principle, then they cannot guarantee order, and the virtual machine can reorder them arbitrarily.
- Program Order rules : Within a thread, in code order, the preceding operation precedes the operation that is written in the back
- Locking rule : A unlock operation occurs after the face of the same locking lock operation.
- volatile Variable rule : The write operation of a variable precedes the read operation that faces the variable.
- Delivery Rules : If the action a thread occurs in action B, and action B occurs first in Operation C, you can conclude that operation a precedes operation C.
- Thread Start rule: the Start () method of the thread object takes precedence over each operation of this thread.
- Thread break rule: the invocation of the thread interrupt () method occurs when the code of the interrupted thread detects the break time.
- Thread termination rule: All operations in a thread occur first in thread termination detection, and we can detect that the thread has terminated execution by means of the Thread.Join () method end, Thread.isalive () return value
- Object Finalization rule: Initialization of an object occurs at the beginning of his finalize () method
- These 8 principles are excerpted from the in-depth understanding of Java virtual machines. The first 4 rules are more important, and the latter 4 are obvious.
What's the use of 4.volatile? Can you describe the volatile application scenario in a sentence?
See volatile in detail.
Volatile can guarantee visibility and a certain order. Because the thread only works in its own workspace, if another thread modifies the value of the variable, the other thread must read from main memory if it needs to read the value of the variable again . This means that the threads that have been read cannot be changed, but the visibility and relative ordering are guaranteed. In addition, the rules of the JVM:volatile variable rules : The write operation of a variable precedes the read operation that faces the variable. This guarantees the order in which the statements will be executed successively. Code that precedes the operation of a volatile tag must be completed before execution can be performed.
Scenario: The state tag amount, used as a condition for thread run, may not read memory tags without volatile, or not know when to read. Code order guarantees that the code before the operation of the volatile tagged variable must be executed. Double check.
Summary of basic Java topics