java的锁实现
同步锁“synchronize”，手动锁Lock
synchronize：自动锁住，自动开锁。（自动都是建立在一定的条件上的）
Lock：手动，手动锁住，手动开锁
具体如何实现，这里不好说，一时说不清，自行搜索。
B. 如何在Java中使用双重检查锁实现单例
一个常见情景，单例类在多线程环境中违反契约。如果你要一个新手写出单例模式，可能会得到下面的代码：
private static Singleton _instance;
public static Singleton getInstance() {
if (_instance == null) {
_instance = new Singleton();
}
return _instance;
}
然后，当你指出这段代码在超过一个线程并行被调用的时候会创建多个实例的问题时，他很可能会把整个getInstance()方法设为同步（synchronized），就像我们展示的第二段示例代码getInstanceTS()方法一样。尽管这样做到了线程安全，并且解决了多实例问题，但并不高效。在任何调用这个方法的时候，你都需要承受同步带来的性能开销，然而同步只在第一次调用的时候才被需要，也就是单例类实例创建的时候。这将促使我们使用双重检查锁模式（double checked locking pattern），一种只在临界区代码加锁的方法。程序员称其为双重检查锁，因为会有两次检查 _instance == null，一次不加锁，另一次在同步块上加锁。这就是使用Java双重检查锁的示例：
public static Singleton getInstanceDC() {
if (_instance == null) { // Single Checked
synchronized (Singleton.class) {
if (_instance == null) { // Double checked
_instance = new Singleton();
}
}
}
return _instance;
}
这个方法表面上看起来很完美，你只需要付出一次同步块的开销，但它依然有问题。除非你声明_instance变量时使用了volatile关键字。没有volatile修饰符，可能出现Java中的另一个线程看到个初始化了一半的_instance的情况，但使用了volatile变量后，就能保证先行发生关系（happens-before relationship）。对于volatile变量_instance，所有的写（write）都将先行发生于读（read），在Java 5之前不是这样，所以在这之前使用双重检查锁有问题。现在，有了先行发生的保障（happens-before guarantee），你可以安全地假设其会工作良好。另外，这不是创建线程安全的单例模式的最好方法，你可以使用枚举实现单例模式，这种方法在实例创建时提供了内置的线程安全。另一种方法是使用静态持有者模式（static holder pattern）。
/*
* A journey to write double checked locking of Singleton class in Java.
*/
class Singleton {
private volatile static Singleton _instance;
private Singleton() {
// preventing Singleton object instantiation from outside
}
/*
* 1st version: creates multiple instance if two thread access
* this method simultaneously
*/
public static Singleton getInstance() {
if (_instance == null) {
_instance = new Singleton();
}
return _instance;
}
/*
* 2nd version : this definitely thread-safe and only
* creates one instance of Singleton on concurrent environment
* but unnecessarily expensive e to cost of synchronization
* at every call.
*/
public static synchronized Singleton getInstanceTS() {
if (_instance == null) {
_instance = new Singleton();
}
return _instance;
}
/*
* 3rd version : An implementation of double checked locking of Singleton.
* Intention is to minimize cost of synchronization and improve performance,
* by only locking critical section of code, the code which creates instance of Singleton class.
* By the way this is still broken, if we don't make _instance volatile, as another thread can
* see a half initialized instance of Singleton.
*/
public static Singleton getInstanceDC() {
if (_instance == null) {
synchronized (Singleton.class) {
if (_instance == null) {
_instance = new Singleton();
}
}
}
return _instance;
}
}
这就是本文的所有内容了。这是个用Java创建线程安全单例模式的有争议的方法，使用枚举实现单例类更简单有效。我并不建议你像这样实现单例模式，因为用Java有许多更好的方式。但是，这个问题有历史意义，也教授了并发是如何引入一些微妙错误的。正如之前所说，这是面试中非常重要的一点。
在去参加任何Java面试之前，要练习手写双重检查锁实现单例类。这将增强你发现Java程序员们所犯编码错误的洞察力。另外，在现在的测试驱动开发中，单例模式由于难以被模拟其行为而被视为反模式（anti pattern），所以如果你是测试驱动开发的开发者，最好避免使用单例模式。转载，仅供参考。
C. java怎么实现redis分布式锁
Redis有一系列的命令，特点是以NX结尾，NX是Not eXists的缩写，如SETNX命令就应该理解为：SET if Not eXists。这系列的命令非常有用，这里讲使用SETNX来实现分布式锁。
用SETNX实现分布式锁
利用SETNX非常简单地实现分布式锁。例如：某客户端要获得一个名字foo的锁，客户端使用下面的命令进行获取：
SETNX lock.foo <current Unix time + lock timeout + 1>
如返回1，则该客户端获得锁，把lock.foo的键值设置为时间值表示该键已被锁定，该客户端最后可以通过DEL lock.foo来释放该锁。
如返回0，表明该锁已被其他客户端取得，这时我们可以先返回或进行重试等对方完成或等待锁超时。
解决死锁
上面的锁定逻辑有一个问题：如果一个持有锁的客户端失败或崩溃了不能释放锁，该怎么解决？我们可以通过锁的键对应的时间戳来判断这种情况是否发生了，如果当前的时间已经大于lock.foo的值，说明该锁已失效，可以被重新使用。
发生这种情况时，可不能简单的通过DEL来删除锁，然后再SETNX一次，当多个客户端检测到锁超时后都会尝试去释放它，这里就可能出现一个竞态条件,让我们模拟一下这个场景：
C0操作超时了，但它还持有着锁，C1和C2读取lock.foo检查时间戳，先后发现超时了。
C1 发送DEL lock.foo
C1 发送SETNX lock.foo 并且成功了。
C2 发送DEL lock.foo
C2 发送SETNX lock.foo 并且成功了。
这样一来，C1，C2都拿到了锁！问题大了！
幸好这种问题是可以避免D，让我们来看看C3这个客户端是怎样做的：
C3发送SETNX lock.foo 想要获得锁，由于C0还持有锁，所以Redis返回给C3一个0
C3发送GET lock.foo 以检查锁是否超时了，如果没超时，则等待或重试。
反之，如果已超时，C3通过下面的操作来尝试获得锁：
GETSET lock.foo <current Unix time + lock timeout + 1>
通过GETSET，C3拿到的时间戳如果仍然是超时的，那就说明，C3如愿以偿拿到锁了。
如果在C3之前，有个叫C4的客户端比C3快一步执行了上面的操作，那么C3拿到的时间戳是个未超时的值，这时，C3没有如期获得锁，需要再次等待或重试。留意一下，尽管C3没拿到锁，但它改写了C4设置的锁的超时值，不过这一点非常微小的误差带来的影响可以忽略不计。
注意：为了让分布式锁的算法更稳键些，持有锁的客户端在解锁之前应该再检查一次自己的锁是否已经超时，再去做DEL操作，因为可能客户端因为某个耗时的操作而挂起，操作完的时候锁因为超时已经被别人获得，这时就不必解锁了。
示例伪代码
根据上面的代码，我写了一小段Fake代码来描述使用分布式锁的全过程：
# get lock
lock = 0
while lock != 1:
timestamp = current Unix time + lock timeout + 1
lock = SETNX lock.foo timestamp
if lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):
break;
else:
sleep(10ms)
# do your job
do_job()
# release
if now() < GET lock.foo:
DEL lock.foo
是的，要想这段逻辑可以重用，使用python的你马上就想到了Decorator，而用Java的你是不是也想到了那谁？AOP + annotation？行，怎样舒服怎样用吧，别重复代码就行。
D. JAVA中的内锁机制是什么
多线程同步的实现最终依赖锁机制。我们可以想象某一共享资源是一间屋子，每个人都是一个线程。当A希望进入房间时，他必须获得门锁，一旦A获得门锁，他进去后就立刻将门锁上，于是B,C,D...就不得不在门外等待，直到A释放锁出来后，B,C,D...中的某一人抢到了该锁（具体抢法依赖于JVM的实现，可以先到先得，也可以随机挑选），然后进屋又将门锁上。这样，任一时刻最多有一人在屋内（使用共享资源）。 Java语言规范内置了对多线程的支持。对于Java程序来说，每一个对象实例都有一把“锁”，一旦某个线程获得了该锁，别的线程如果希望获得该锁，只能等待这个线程释放锁之后。获得锁的方法只有一个，就是synchronized关键字。
E. java分布式锁的实现方式有哪些
之前在itjob技术群讨论过这个1、数据库级别控制，乐观锁控制2、类似zookeeper做一个远程单点锁，每次取锁、加锁、释放锁
还有没有更优解，上面两种哪个好点
简单说就是http请求，100ms内两个同样的请求，{查询接口拿一个key和一个数值，然后+1，请求新数值}，加{}的这个过程希望相同key的请求能够串行，否则设置新值会有并发问题
F. java多线程‘锁’,是用什么锁的,有方法
多线程的同步锁通过synchronized实现
有俩种方式 一种是在代码块加锁
代码块加锁时可以指定任意类的实例过的对象
即锁在这个对象上（任何对象都有一个锁）
使同一时间内只有一个线程可以访问到代码块中
另外一种就是以synchronized关键字修饰方法
这时加锁的对象就是类本身的实例 即this
以上 O(∩_∩)O
G. java怎么实现redis分布式锁
一、使用分布式锁要满足的几个条件：
系统是一个分布式系统（关键是分布式，单机的可以使用ReentrantLock或者synchronized代码块来实现）
共享资源（各个系统访问同一个资源，资源的载体可能是传统关系型数据库或者Nosql）
同步访问（即有很多个进程同事访问同一个共享资源。没有同步访问，谁管你资源竞争不竞争）
二、应用的场景例子
管理后台的部署架构（多台tomcat服务器+redis【多台tomcat服务器访问一台redis】+mysql【多台tomcat服务器访问一台服务器上的mysql】）就满足使用分布式锁的条件。多台服务器要访问redis全局缓存的资源，如果不使用分布式锁就会出现问题。 看如下伪代码：
long N=0L;
//N从redis获取值
if(N<5){
N++；
//N写回redis
}
复制代码
H. JAVA编程同步，加锁如何实现，有何优缺点
加锁的方式有非常多，可以在程序上使用。或者是在数据库上操作。保证事务一致性即可
I. Java 集群锁如何实现
1. 用数据库，在数据库建一张表，需要锁的节点都可以尝试用 select * from Lock where id=xx for update. 这个时候只有一个节点能拿到结果，其它的都会等待，就能实现一个简单的悲观锁。
2. 用 Zookeeper 来做分布式锁，具体可以搜一下。
3. 自己实现，搞个节点来做这个事情，所有要获取锁的都走 RPC 调用来请求锁，用完以后记得释放，不然其他的节点就会挂那里。