synchronized无法判断获取锁的状态，lock可以判断是否获取到了锁。

synchronized和Lock两种加锁方式的区别中，
synchronized无法判断获取锁的状态，lock可以判断是否获取到了锁。
这句话可以有人帮忙解释一下吗，lock通过什么方法获取到锁的？
还有我看了这篇文章，怎么就看不懂呢。不是说synchronized无法判断获取锁的状态吗.
https://blog.csdn.net/w410589502/article/details/54949506

1.获取方法

lock()、tryLock()、tryLock(long time, TimeUnit unit) 和 lockInterruptibly()都是用来获取锁的。

（1）lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。

（2）tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true，如果获取失败（即锁已被其他线程获取），则返回false，也就说这个方法无论如何都会立即返回。在拿不到锁时不会一直在那等待。

（3）tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false。如果如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。

（4）lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程正在等待获取锁，则这个线程能够响应中断，即中断线程的等待状态。也就使说，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

拿可重入锁来说（公平锁模式吧）lock的返回结果，其实就是判断是否抢占到了锁
AbstractQueuedSynchronizer的核心方法getState

，
如果为0，则表示没有被抢占资源，此时如果它存在等待队列的第一位（header节点的下一个节点，不算严格意义的第一位，）会去使用cas去修改state，这时候这个等待队列的第一位线程则成功抢占到锁，方法也是直接返回true了，至于重入场景下锁资源的判断，则是第二个if，逻辑简单多了，第一次抢占资源成功后，将当前线程设置为独占线程，这个时候只要判断此时你运行的这个线程和独占线程是不是同一个线程，这就判断拿不拿到锁了
ps：非公平锁则是每一个线程都去使用cas修改state，但是只会有一个修改成1，其他人如果没有修改成功，这时候直接就是抢占锁失败了）