Java lock mechanism, synchronize and lock comparison __java

With the frontline synchronization only know the Synchronize keyword, then know that there is a lock, why also have a lock to achieve synchronization? Synchronized's limitations occupy the lock thread waiting for IO or other reasons to be blocked, without releasing the lock, Read and read can also conflict when other threads are blocking multiple threads at the same time reading and writing files we have no way of knowing whether our thread has successfully acquired the lock and can only wait innocently

There are these restrictions on all other synchronization mechanisms to solve, so there is a lock,lock commonly used two interfaces and two implementations
First, lock interface, let's look at its definition

Package java.util.concurrent.locks;
Import Java.util.concurrent.TimeUnit;

Public interface Lock {

    void lock ();

    void Lockinterruptibly () throws interruptedexception;

    Boolean trylock ();

    Boolean Trylock (long time, Timeunit unit) throws interruptedexception;

    void unlock ();

    Condition newcondition ();
}

The effect of these methods isLock () Gets the lock, does not get the wait, no return value lockinterruptibly () Gets the lock waiting, no return value, but can be interrupted by the Thread.Interrupt () method, throws an exception Trylock () Gets the lock, does not wait, Returns whether a successful Trylock (long time, timeunit unit) Gets the lock, does not get the wait specified time, returns whether succeeds, waits can be interrupted by the Thread.Interrupt () method, throws an exception unlock () releases the lock Newcondition () implements the interaction between threads and corresponds to the wait,notify,notify of the object
Two ways of realizing producer consumers release of lock on synchronize and lockSynchronize one of the following three conditions to release a lock
The thread that owns the lock executes the thread exception that occupies the lock the thread that exited the lock has entered the waiting state release lock lock must call the Unlock () method
The only implementation reentrantlock of the lock interface, which means that the lock can be reentrant and can be introduced after the lock.

Second, Readwritelock interface, let's look at its definition

Package java.util.concurrent.locks;

Public interface Readwritelock {
    /**
     * Returns the lock used for reading.
     *
     @return The lock used for reading *
    /Lock Readlock ();

    /**
     * Returns the lock used for writing.
     *
     @return The lock used for writing *
    /Lock Writelock ();
}

Annotations are written very clearly, in order to resolve issues that are mutually exclusive for two simultaneous read operations
Reentrantreadwritelock () for the implementation of the Readwritelock interface The concept of some locks can be reentrant. Multiple code blocks and methods that call the same thread with the lock do not repeat the lock, SY and lock and Readwritelock are reentrant locks that can be interrupted during the wait, lockinterruptibly () acquire an interruptible lock, and an interrupt throws an abnormally fair lock. The two locks described above can be added to the Boolean constructor parameters, the default is a fair lock, multiple threads waiting at the same time, the current thread execution, random execution of the next thread, fair Lock is first to perform read and write lock, read and write lock, that is, read lock and write lock is separate