The main contents of this paper are as follows:

This article has been uploaded to my Java online documentation, Github: passjava-Learning

My SpringCloud field project is constantly updated

A, the transaction

1.1 What are transactions

A sequence of operations performed for a single unit of work. Such as query, modify data, modify data definition.

1.2 grammar

(1) Display the start and commit of the defined transaction

BEGIN` `TRAN``INSERT` `INTO` `b(t1) ``VALUES``(1)``INSERT` `INTO` `b(t1) ``VALUES``(2)``COMMIT` `TRAN
Copy the code

(2) Implicit definition

If the boundaries defining transactions are not shown, SQL Server defaults to treating each individual statement as a transaction, meaning that the transaction is committed automatically after each statement is executed.

1.3 Four properties of transaction ACID

(1) Atomicity

• 1. Transactions must be atomic units of work. All or none of the changes made in the transaction are executed;

• 2. Before the transaction completes (before the commit instruction is recorded in the transaction log), if the system fails or restarts, SQL Server will undo all changes made in the transaction;

• 3. When a transaction encounters an error during processing, SQL Server usually rolls back the transaction automatically.

• 4. A few minor errors do not cause automatic rollback of transactions, such as primary key conflicts, lock timeouts, etc.

• 5. You can use error handling to catch the error mentioned in Point 4 and take some action, such as logging the error and rolling back the transaction;

• 6.SELECT @@TranCount can be used anywhere in the code to determine whether the current use of SELECT @@TranCount is in an open transaction. If it is not in the scope of any open transaction, this function returns 0. Returns a value greater than 0 if it is within the return range of an open transaction. Open a transaction, @@tranCount = @@tranCount +1; Commit a transaction, @@trancoun-1.

It is Consiitency

• 1. Simultaneous transactions do not conflict when modifying and querying data;

• 2. Consistency depends on the needs of the application. We’ll talk about consistency levels and how to control them later.

(3) Isolation

• 1. Used to control data access and ensure that transactions only access data at the desired consistency level;

• 2. Use locks to isolate data being modified and queried between transactions.

(4) Durability

• 1. Write the transaction log, modify the data written to the disk database will put these changes before the data partition in the database transaction log written to disk, the submission instructions in the transaction log records to disk, real-time data change has not yet been applied to the data from disk partitions, can also think that transaction is persistence.

• 2. System restart: If the system is restarted normally or after a system fault occurs, SQL Server will reply the transaction logs of each database.

• 3. The recovery process consists of two phases: redo phase and undo phase.

• 4. Roll forward: In the redo phase, for transactions where commit instructions have been written to the log, but the data changes have not been applied to the data partition, the database engine will redo all the changes made by these foods.

• 5. Rollback: During the undo phase, the database engine will undo the changes made by transactions for which commit instructions are not written to the log. (This sentence requires research and may not be correct. Because the commit instruction is not written to the data partition, what changes does undo mean to undo?

Second, the lock

2.1 Locks in transactions

(1) SQL Server uses locks to achieve transaction isolation.

(2) Transaction acquisition lock is a control resource used to protect data resources and prevent other transactions from conflicting or incompatible access to data.

2.2 the lock mode

(1) Exclusive lock

• A. When attempting to modify data, a transaction can only request an exclusive lock for the data resource on which it depends.

• B. Hold exclusive lock duration: Once a transaction has acquired an exclusive lock, the transaction will hold the exclusive lock until the transaction completes.

• C. Exclusive locks and any other type of locks cannot be applied to the same resource at the same stage in multiple transactions.

For example, if the current transaction acquires an exclusive lock on a resource, other transactions cannot acquire any other type of lock on that resource. If other transactions acquire any other type of lock on a resource, the current transaction cannot acquire an exclusive lock on that resource.

(2) Shared lock

• A. When attempting to read data, the transaction defaults to requesting a shared lock for the data resource on which it depends.
• B. Hold the shared lock time: from the time the transaction obtains the shared lock to the time the read operation completes.
• C. Multiple transactions can act on the same data resource at the same stage with a shared lock.
• D. Control over how locking is handled when data is read. How locking is controlled is covered in isolation levels later.

2.3 Compatibility between Exclusive locks and shared locks

(1) If data is being modified by one transaction, other transactions can neither modify it nor (at least by default) read it until the first transaction completes.

(2) If data is being read by one transaction, it cannot be modified by other transactions (at least by default).

2.4 Types of resources that can be locked

Rids, keys, pages, objects (such as tables), databases, extents, allocation_units, HEAP, and B-trees.

RID: Identifies a specific row on a page

• Fileid: Pagenumber: RID (1:109:0)

Fileid identifies the file that contains pages, Pagenumber identifies the page that contains rows, and RID identifies the specific row on the page.

The fileID matches the file_ID column in the sys.databases_files directory view

• Example:

When querying sys. dM_tran_LOCKS, the resource_description column displays RID at 1:109:0 and the status column displays wait.

Represents the lock resource on line 0 on page 109 on the first data file.

2.5 lock escalation

SQL Server can start by acquiring fine-grained locks (such as rows or pages), and in some cases upgrade fine-grained locks to coarse-grained locks (for example, tables). For example, if a single statement obtains at least 5000 locks, the lock upgrade is triggered. If the lock cannot be upgraded due to lock conflicts, the SQL Server starts the lock upgrade every time the SQL Server obtains 1250 new locks.

Third, blocking

3.1 the blocked

Blocking occurs by default when multiple transactions need to lock a resource. Blocked requests wait until the original transaction releases the associated lock. The lock timeout period can be limited, which limits how long a blocked request must wait before it times out.

• Phase 1: Transaction A requests resource S1, and the transaction does not operate on resource S1

• Phase 2: Transaction A locks resource S1 with lock A. Transaction B requests an incompatible lock (lock B) on resource S1. The request for lock B is blocked and transaction B enters the wait state

• Phase 3: Transaction A is releasing lock A, transaction B is waiting for lock A to release,

• Phase 4: Transaction A’s lock A is released, and transaction B locks resource S1 with lock B

3.2 Troubleshooting the blocking problem

Example:

3.2.1 Preparations:

• 1. Prepare test data

Create a table Product as a test. Where id is the primary key of the table, CREATE TABLE [dbo].[myProduct]([id] [int] NOT NULL, [price] [money] NOT NULL ON [PRIMARY] GO Id = 1, price = 10 INSERT INTO [TSQLFundamentals2008] [dbo]. [myProduct] ([id], [price]) VALUES (1, 10)Copy the code

• 2. Simulate a blocking situation

Open three query Windows Connection1, Connection2, Connection3 in SQL Server, and execute the execution statements in the table in sequence respectively.

--Connection1
BEGIN TRAN
UPDATE dbo.myProduct SET price = price + 1 WHERE id=1
Copy the code

Conclusion 1:

To update the row id=1, the session must first acquire an exclusive lock. The transaction is always open and not committed, so the transaction holds an exclusive lock until the transaction commits and completes.

--Connection2
SELECT * FROM dbo.myProduct WHERE id=1
Copy the code

Conclusion 2:

In order to read data, a transaction needs to request a shared lock, but this row is already locked by an exclusive lock held by another session, and shared locks and exclusive locks are not compatible, so the session is blocked and goes into a wait state

--Connection3
SELECT  request_session_id ASSession ID, resource_typeASType of resource to be locked, resource_descriptionASDescription, request_modeASMode, request_statusASstateFROM    sys.dm_tran_locks
Copy the code

Conclusion 3: **

Session 56: (1) State wait-wait lock

(2) Waiting for a shared lock for the resource at line 0 on page 109 of the first data file

(3) The intent to share the lock that holds the resource on page 109 on the first data file

(3) Hold OBJECT resources and intend to share locks

(4) Hold DATABASE resources and intend to share locks

52 session:

(1) State WAIT- grant lock

(2) Waiting for an exclusive lock on the resource on line 0 on page 109 of the first data file (3) holding an exclusive lock on the resource on page 109 of the first data file

(3) Hold OBJECT resource, exclusive lock

(4) Hold DATABASE resources, exclusive lock

The demo and summary are as follows:

3.2.2 Analyzing the cause of congestion

3.2.2.1 sys. Dm_tran_locks view

(1) The dynamic view can query which resources are locked by which process ID

(2) Query the lock mode granted or waiting for the resource

(3) Query the type of the locked resource

Query statement 3 above already uses this view, as illustrated in the analysis above.

3.2.2.2 sys. Dm_exec_connections view

(1) Query the dynamic view to query the process related information

(2) Query the time of the last read and write operation last_read,last_write

(3) Query most_recent_SQL_HANDLE binary flag of the last SQL batch executed by the process

SELECT  session_id ,
        connect_time ,
        last_read ,
        last_write ,
        most_recent_sql_handle
FROM    sys.dm_exec_connections
 
WHERE   session_id IN ( 52.56 )
Copy the code

Conclusion:

52 session:

(1) Connect_time Connection time: 2016-06-07 07:09:41.103

(2) last_read Last read operation time: 2016-06-07 07:10:56.233

(3) last_write Last write operation time: 2016-06-07 07:10:57.873

(4) MOST_recENT_SQL_HANDLE This is a binary flag, the last SQL batch

Session 56:

(1) State WAIT- grant lock

(2) Waiting for an exclusive lock on the resource on line 0 on page 109 of the first data file (3) holding an exclusive lock on the resource on page 109 of the first data file

(3) Hold OBJECT resource, exclusive lock

(4) Hold DATABASE resources, exclusive lock

The demo and summary are as follows:

3.2.2.3 sys. dM_EXEC_SQL_TEXT Table function

Example:

BEGIN TRAN UPDATE Dbo. myProduct SET price = price + 1 WHERE ID = 1 Session 56: SQL statement executed:  (@1 tinyint) SELECT * FROM [dbo].[myProduct] WHERE [id]=@1Copy the code

(1) This function can take the binary flag MOST_recent_SQL_HANDLE as an argument and return the SQL code.

(2) The blocking process is constantly running, so the last action you see in the code is not necessarily the statement that caused the problem. The last execution statement in this case is the statement that causes the block.

SELECT  session_id ,
        text
FROM    sys.dm_exec_connections
        CROSS APPLY sys.dm_exec_sql_text
        (most_recent_sql_handle) AS ST
WHERE   session_id IN ( 52.56 )

Copy the code

The demo and summary are as follows:

3.2.2.4 sys. Dm_exec_sessions view

(1) Time when the session is established login_time

(2) Session-specific client workstation name host_name

(3) The name of the client program that initializes the session, program_name

(4) SQL Server login name login_name used by the session

(5) Start time of the latest request last_request_start_time

(6) Last_request_end_time indicates the completion time of the latest request

SELECT * FROM sys.dm_exec_sessions
Copy the code

The demo and summary are as follows:

3.2.2.5 sys. Dm_exec_requests view

(1) Identify the sessions involved in the blocking chain, the resources in contention, and how long the blocked session waits

SELECT * FROM sys.dm_exec_sessions
Copy the code

Conclusion:

Session 56:

Session 52 blocking_session_id = 52

(2) Start time of session 52 start_time

(3) Status = suspended

(4) Suspend command

The demo and summary are as follows:

3.2.3 Solve the congestion problem

3.2.3.1 Lock_TIMEOUT options

(1) Set the timeout period for the session to wait for lock release

(2) By default, the session does not set the timeout period for waiting for lock release

(3) SET the session timeout period to 5 seconds. SET Lock_TIMEOUT 5000

(4) If the lock times out, the transaction will not be rolled back

(5) Cancel the session timeout lock setting, SET lock_timeout-1

If you time out, the following error is displayed:

3.2.3.1 KILL command

(1) KILL session 52, KILL 52

(2) Killing the session causes the transaction to roll back and releases the exclusive lock

Iv. Isolation level

4.1 Basic Concepts

(1) What is the isolation level used for

• A. The isolation level determines how to control data read and write operations by concurrent users

(2) Write operation

• A. Any statement that changes the table

• B. Use exclusive locks

• C. The lock obtained by a read operation and the lock duration cannot be modified

(3) Read operation:

• A. Any statement that retrieves data

• B. The shared lock is used by default

• C. Use isolation levels to control the processing of read operations

4.2 Classification of isolation levels

(1) READ UNCOMMITTED

(2) READ COMMITTED (default)

(3) REPEATABLE READ

(4) SERIALIZABLE

(5) SNAPSHOT

(6) Read snapshot has been committed (READ_COMMITTED_SNAPSHOT)

4.3 Setting the Isolation Level

(1) Set the isolation level for the entire session

SET TRANSACTION ISOLATION LEVEL <isolation name>;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Copy the code

(2) Use table prompts to set the isolation level of the query

SELECT.FROM <table> WITH (<isolation name>);
SELECT * FROM dbo.myProduct WITH (READCOMMITTED);
Copy the code

Note:

• 1. When setting the isolation level of session options, separate each word in the isolation level with a space

• 2. When using the isolation levels suggested by the table, each word in the isolation level does not need to be separated by a space

• 3. The isolation levels displayed in the table have synonyms, such as NOLOCK->READUNCOMMITTED,HOLDLOCK->REPEATABLEREAD

• 4. Isolation level rigor: 1. Uncommitted reads <2. Committed reads <3. serializable

• 5. The higher the isolation level, the higher the consistency and the lower the concurrency

• 6. Based on the isolation level of snapshots, SQL Server stores committed rows in the TEMPDB database, and when a read finds that the current version of the row is inconsistent with their expected version, it can immediately retrieve the previous version of the row, thus achieving the desired consistency without requiring a shared lock.

4.4 Behavior of isolation levels

4.4.1 READ UNCOMMITTED

Open two query Windows, Connetion1 and Connection2

• Step1: execute the SQL statement for phase 2 of Connection1, and then execute the SQL statement for connection2

• Step2: execute the SQL statement of phase 3 of Connection1 and the SQL statement of connection2

• Step3: execute the SQL statement in phase 4 of Connection1 and the SQL statement in phase 2 of connection2

- phase 2
UPDATE  myProduct
SET     price = price + 1
WHERE   id = 1;
  
SELECT  id ,
        price
FROM    dbo.myProduct
WHERE   id = 1;
  
- phase 3
UPDATE  myProduct
SET     price = price + 5
WHERE   id = 1;
  
SELECT  id ,
        price
FROM    dbo.myProduct
WHERE   id = 1;
  
- phase 4
COMMIT TRAN
Copy the code

-- After phase 2 execution
SET TRAN ISOLATION LEVEL READ UNCOMMITTED
BEGIN TRAN;
SELECT  id ,
        price
FROM    dbo.myProduct
WHERE   id = 1
 
COMMIT TRAN;
Copy the code

Flowchart of two transactions:

• Phase 1: Price=10, transaction A requests an exclusive lock on the myProduct table

• Phase 2: Transaction A uses an exclusive lock on myProduct, updates price= price + 1, and then queries the price of price: price=11. Transaction B does not request any locks. Transaction B queries after A updates Price, Price =11

• Phase 3: Transaction A updates price = price + 5, then transaction A queries the price of price, price = 16. Transaction B queries price: price=16

• Phase 4: Transaction A releases the exclusive lock

• Phase 5: Query price in transaction A for price :price = 16. Transaction B queries price: price=16

As you can see, transaction B has two outcomes, which is what the “READ UNCOMMITTED” isolation level means:

(1) Read operations can read uncommitted changes (also known as dirty reads).

(2) The read operation does not prevent the write operation from requesting the exclusive lock. The write operation can modify the data while other transactions are reading.

(3) Transaction A has been modified for many times, and transaction B may have different results when it queries at different stages.

4.4.2 READ COMMITTED (Default)

Open two query Windows, Connetion1 and Connection2

Step1: execute the Connection1 SQL statement

UPDATE` `dbo.myProduct ``SET` `price = price + 1` `WHERE` `id=1
SELECT` `*` `FROM` `dbo.myProduct ``WHERE` `id =1
Copy the code

Step2: Execute the Connection2 SQL statement

SET` `TRANSACTION` `ISOLATION` `LEVEL` `READ` `COMMITTED
SELECT` `*` `FROM` `dbo.myProduct ``WHERE` `id = 1
Copy the code

Flowchart of two transactions:

• Phase 1: Price=10, transaction A requests an exclusive lock on the myProduct table

• Phase 2: Transaction A uses an exclusive lock on myProduct, updates price= price + 1, and then queries the price of price: price=11. Transaction B then requests the shared lock to read, and queries price,

Because at the current isolation level, transaction A’s exclusive lock conflicts with transaction B’s shared lock, transaction B needs to wait for transaction A to release the exclusive lock before reading data.

• Phase 3: Transaction A Commits transaction (COMMIT TRAN)

• Phase 4: After transaction A commits the transaction, the exclusive lock is released

• Phase 5: Transaction B acquires the shared lock and reads, price=11

  What the READ UNCOMMITTED isolation level means:

(1) Read operations can only be performed if a shared lock is obtained. If other transactions hold an exclusive lock on the resource, the shared lock must wait for the exclusive lock to be released.

(2) Read operations cannot read uncommitted changes. The data read by read operations is committed changes.

(3) Read operations do not retain the shared lock for the duration of the transaction, and other transactions can change the data resource between the two read operations, so that read operations may get different values each time. This phenomenon is called “non-repeatable reads”

4.4.3 REPEATABLE READ

Open two query Windows, Connetion1 and Connection2

Step1: execute the Connection1 SQL statement

SET` `TRANSACTION` `ISOLATION` `LEVEL` `REPEATABLE` `READ
SELECT` `*` `FROM` `dbo.myProduct ``WHERE` `id = 1
Copy the code

Step2: Execute the Connection2 SQL statement

UPDATE` `dbo.myProduct ``SET` `price = price + 1` `WHERE` `id=1   
Copy the code

The demo and summary are as follows:

Flowchart of two transactions:

• Phase 1: Price=10, transaction A requests A shared lock on the myProduct table

• Phase 2: Transaction A uses A shared lock on the myProduct table. Transaction A queries the price of price: price=10 and holds the shared lock until transaction A completes. Transaction B then requests an exclusive lock to write

Because at the current isolation level, transaction A’s shared lock conflicts with the exclusive lock requested by transaction B, transaction B needs to wait for transaction A to release the shared lock before modifying data.

• Phase 3: transaction A queries price, price=10, indicating that the update operation of transaction B is blocked and the update operation is not executed. Then transaction A commits the transaction (COMMIT TRAN)

• Phase 4: After transaction A commits, the shared lock is released

• Phase 5: Transaction B acquires an exclusive lock and writes, price=11

** The meaning of “REPEATABLE READ” isolation level: **

(1) A shared lock must be acquired to perform read operations. The shared lock will remain until the transaction completes.

(2) Before the transaction that acquired the shared lock is completed, no other transaction can obtain the data resource of the exclusive lock modification, so that repeatable reads can be guaranteed.

(3) Both transactions retain the shared lock they acquired after the first read operation, so neither transaction can acquire the exclusive lock that it needs to update the data. This situation causes a deadlock, but avoids update conflicts.

4.4.4 SERIALIZABLE (SERIALIZABLE)

Open two query Windows, Connetion1 and connection2. Step1: execute the SQL statement for Connection1

BEGIN TRANSACTION
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE   
SELECT * FROM dbo.myProduct WHERE id = 1
Copy the code

Step2: Execute the Connection2 SQL statement

INSERT` `INTO` `dbo.myProduct(id, price) ``VALUES` ` (1.20)
Copy the code

The demo and summary are as follows:

Flowchart of two transactions:

• Phase 1: Price=10, transaction A requests A shared lock on the myProduct table

• Phase 2: Transaction A uses A shared lock on myProduct. Transaction A queries the price of price with id=1 and price=10. Transaction A holds the shared lock until transaction A completes. Transaction B then requests an exclusive lock for insert operation id=1,price=20,

Because at the current isolation level, transaction B tries to add new rows that can meet the query search criteria of transaction A’s read operation, the shared lock of transaction A conflicts with the exclusive lock of transaction B’s request, and transaction B needs to wait for transaction A to release the shared lock before inserting data.

• Phase 3: Transaction A finds only 1 row of data with ID =1, indicating that transaction B’s insert operation is blocked and the insert operation is not executed. Then transaction A commits the transaction (COMMIT TRAN)

• Phase 4: After transaction A commits, the shared lock is released

• Phase 5: Transaction B obtains an exclusive lock, inserts the lock, inserts the lock successfully, and finds two – for the data whose ID =1

The SERIALIZABLE isolation level means:

(1) A shared lock must be acquired to perform read operations. The shared lock will remain until the transaction completes.

(2) the transaction is complete before get the Shared lock, no other transactions can get exclusive lock to modify the data resources, increased while the rest of the transaction and can meet the current transaction reads query search condition of a new row, other issues will be blocked, until the current transaction is complete and then release the Shared lock, other issues to get exclusive locks to insert.

(3) The read operation in the transaction in any case to read the data is consistent, will not appear phantom line (phantom read).

(4) Range lock: Read operations lock locks that meet the range of search criteria.

4.5 Isolation Level Summary

Dirty read: Reads uncommitted changes.

Non-repeatable reads: Read operations do not retain the shared lock for the duration of the transaction, and other transactions can change the data resource between the two reads, so that the read operation may obtain different values each time.

Lost update: Two transactions read the data and acquire the shared lock on the resource. After reading the data, they no longer hold any locks on the resource. Both transactions can update this value.

Phantom read: The number of rows read on the first and second time is inconsistent.

Range lock: Locks locks that meet the range of search criteria

5. A deadlock

A deadlock is a condition in which processes permanently block each other, possibly involving two or more processes.

Open two query Windows, Connetion1 and Connection2

Step1: execute the Connection1 SQL statement

SET` `TRANSACTION` `ISOLATION` `LEVEL` `READ` `COMMITTED
BEGIN` `TRAN
UPDATE` `dbo.myProduct ``SET` `price = price + 1` `WHERE` `id=1
SELECT` `*` `FROM` `dbo.myOrder ``WHERE` `id =1
Copy the code

Step2: Execute the Connection2 SQL statement

SET` `TRANSACTION` `ISOLATION` `LEVEL` `READ` `COMMITTED
BEGIN` `TRAN
UPDATE` `dbo.myOrder ``SET` `customer =` `'ddd'` `WHERE` `id = 1
SELECT` `*` `FROM` `dbo.myProduct ``WHERE` `id = 1
Copy the code

The demo and summary are as follows:

Flowchart of two transactions:

• Phase 1: Price=10, transaction A requests an exclusive lock on the myProduct table. Customer = aaa, transaction B requests an exclusive lock on myOrder

• Phase 2: Transaction A uses an exclusive lock on the myProduct table, updating price = price + 1. Transaction B then uses an exclusive lock on the myOrder table, updating Customer = DDD.

• Phase 3: Transaction A queries the myOrder table and requests A shared lock on the myOrder table. Transaction A is blocked because the shared lock on transaction A’s request conflicts with the exclusive lock on transaction B. Transaction B then queries the myProduct table and requests A shared lock on the myProduct table. Transaction B is blocked because the shared lock on transaction B’s request conflicts with the exclusive lock on transaction A.

• Phase 4: Transaction A waits for the exclusive lock of transaction B to be released, and transaction B waits for the exclusive lock of transaction A to be released, causing A deadlock. Both transaction A and transaction B are blocked.

• Phase 5: SQL Server detects a deadlock within a few seconds, selects a transaction as the victim of the deadlock, terminates the transaction, and rolls back the operations done by the transaction. In this example, transaction A is terminated with the message that transaction (process ID 53) and another process are deadlocked on the lock resource and have been selected as deadlock victims. Rerun the transaction.

Some considerations for “Dead locks” :

(1) If no deadlock priority is set for two transactions and the amount of work performed is about the same, either transaction may be terminated.

(2) Unlocking deadlocks costs some overhead because the process involves undoing already executed processing.

(3) The longer the transaction processing time, the longer the lock holding time, the greater the possibility of deadlock, should be kept as short as possible, the operation can logically not belong to the same unit of work to move out of the transaction.

(4) In the above example, transaction A and transaction B access resources in reverse order, so A deadlock occurs. This type of deadlock does not occur if two transactions access resources in the same order. Deadlocks can be solved by swapping the order without changing the logic of the program.

I am Wukong, a code farmer trying to become stronger! I’m gonna be super Saiyan!

Hello, I am Wukong Brother, 7 years of project development experience, full stack engineer, development team leader, love graphic programming basic principles. I am writing two PDFS, which are 1, Spring Cloud Practical project (must pass), 2, Java concurrency must know and must know. I also handwritten 2 small program, Java brush small program, PMP brush small program, click on my public menu to open! In addition, 111 architect materials and 1000 Java interview questions have been compiled into PDF. You can follow the public account “Wukong Chat architecture” and reply to Wukong to receive high-quality materials.

Forward -> see -> like -> favorites -> comment!! Is the biggest support for me!

Java Concurrency Must Know must Know series:

1. Counter the interviewer | | 14 zhang diagram is no longer afraid of being asked a volatile!

2. Late-night programmer despised by his wife because CAS is too simple?

3. The principle of with blocks on ABA | wife incredibly understand again!

4. Cut the finest | 21 picture with you appreciate collection thread unsafe

5.5000 word | 24 picture show you thoroughly understand the 21 kinds of locks in Java