01 Thread Safety

The thread-safe explanation is that if your code is in a process where multiple threads are running concurrently, these threads may run the code at the same time. If the result of each run is the same as the single-threaded run, and the value of the other variable is the same as expected, it is thread-safe. Thread safety issues are caused by global variables and static variables. In general, this global variable is thread-safe if there are only read operations on global variables, static variables in each thread, and in general, thread synchronization is generally required if multiple threads are concurrently performing write operations, otherwise it may affect thread safety for sequential or concurrent operations on instances of thread-safe classes. Does not cause the instance to be in an invalid state. 1. What is invalid status

Stateless threads are always thread-safe. For example:

public class Statelessservlet extends httpservlet {@Overrideprotected void service (HttpServletRequest request, HttpServletResponse response) throws Servletexception, ioexception {int =n; System.out.println ("I do not affect other processes");}}   

When we define a state element, a global variable, and then operate in the service, it is not thread-safe.

public class Statelessservlet extends httpservlet {private int count = 0; @Overrideprotected void Service (Httpserv Letrequest request, HttpServletResponse response) throws Servletexception, ioexception {int integer = +; count+ +; System.out.println ("I do not affect other processes");}}     

When two threads are called, the actual should be equal to 12, but may appear equal to 11 in the process of processing, relative to other operations in the same state, must be atomic or indivisible, in order to avoid competition conditions, other threads must be prevented from accessing the variable we are modifying, Make sure to get closer when we're done with the changes. 2. Lock built-in lock mechanism: synchronized block (consisting of lock object reference, lock protected code block), synchronized method lock (lock object itself, if static synchronized method, get lock from class object) synchronized(lock){ 访问或修改被锁保护的共享状态 }The internal lock acts as a mutex, and the lock is automatically acquired before the scene enters the synchronized block, such as a Java object (which can be implicitly used as a synchronous lock). Locks are automatically released when exiting normally or exiting from the exception code base. The only path that gets the lock: the synchronization block or method that enters the internal lock protection. It is not recommended to do this (add a sync lock to the service's method)

public class Statelessservlet extends httpservlet {private int count = 0; @Overrideprotected synchronized void serv Ice (HttpServletRequest request, httpservletresponse response) throws Servletexception, ioexception {int integer = count++; System.out.println ("I do not affect other processes");}}     

For each invariant constraint that involves multiple variables, the same lock is required to protect all of its variables. [Self-understanding: When we need to modify multiple variables, we must ensure that these variables are under the same lock] 3. Activity and performance above we have added a synchronous lock on the service method, but this will cause multiple requests queued to receive processing one after the other, can not synchronize the request service method, expensive, service is processing multi-request, it is obviously unreasonable, Workaround: Reduce the scope of the synchronized to maintain field security, which can easily improve thread safety. Usually the simplicity and performance are mutually constrained, when implementing a synchronization strategy, do not prematurely for performance and sacrifice simple, some time-consuming calculations or operations, such as network or console I/O, difficult to complete quickly, do not occupy locks during these operations.

01 Thread Safety