Ⅰ 在java中有哪些锁
给你整理了Java中的一些锁：
公平锁/非公平锁
可重入锁
独享锁/共享锁
互斥锁/读写锁
乐观锁/悲观锁
分段锁
偏向锁/轻量级锁/重量级锁
自旋锁
上面是很多锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计
Ⅱ java多线程‘锁’,是用什么锁的,有方法
synchronized关键字可以让你对一个对象加锁，
比如synchronized(this);表示对当前类对象加锁，这是一个排他所，即只有一个线程可以访问被synchronized的对象
Ⅲ java中的锁有哪几种
lock比synchronized比较如下：
1) 支持公平锁，某些场景下需要获得锁的时间与申请锁的时间相一致，但是synchronized做不到
2) 支持中断处理，就是说那些持有锁的线程一直不释放，正在等待的线程可以放弃等待。如果不支持中断处理，那么线程可能一直无限制的等待下去，就算那些正在占用资源的线程死锁了，正在等待的那些资源还是会继续等待，但是ReentrantLock可以选择放弃等待
3) condition和lock配合使用，以获得最大的性能
JAVA中锁使用的几点建议：
1.如果没有特殊的需求，建议使用synchronized，因为操作简单，便捷，不需要额外进行锁的释放。鉴于JDK1.8中的ConcurrentHashMap也使用了CAS+synchronized的方式替换了老版本中使用分段锁（ReentrantLock）的方式，可以得知，JVM中对synchronized的性能做了比较好的优化。
2.如果代码中有特殊的需求，建议使用Lock。例如并发量比较高，且有些操作比较耗时，则可以使用支持中断的所获取方式；如果对于锁的获取，讲究先来后到的顺序则可以使用公平锁；另外对于多个变量的锁保护可以通过lock中提供的condition对象来和lock配合使用，获取最大的性能。
Ⅳ Java中有哪些锁，区别是什么
【1】公平所和非公平所。
公平锁：是指按照申请锁的顺序来获取锁，
非公平所：线程获取锁的顺序不一定按照申请锁的顺序来的。
//默认是不公平锁，传入true为公平锁，否则为非公平锁
ReentrantLock reentrantLock = new ReetrantLock();
1
2
【2】共享锁和独享锁
独享锁：一次只能被一个线程所访问
共享锁：线程可以被多个线程所持有。
ReadWriteLock 读锁是共享锁，写锁是独享锁。
【3】乐观锁和悲观锁。
乐观锁：对于一个数据的操作并发，是不会发生修改的。在更新数据的时候，会尝试采用更新，不断重入的方式，更新数据。
悲观锁：对于同一个数据的并发操作，是一定会发生修改的。因此对于同一个数据的并发操作，悲观锁采用加锁的形式。悲观锁认为，不加锁的操作一定会出问题，
【4】分段锁
1.7及之前的concurrenthashmap。并发操作就是分段锁，其思想就是让锁的粒度变小。
【5】偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价
轻量级锁
重量级锁
【6】自旋锁
自旋锁
Ⅳ Java 集群锁如何实现
1. 用数据库，在数据库建一张表，需要锁的节点都可以尝试用 select * from Lock where id=xx for update. 这个时候只有一个节点能拿到结果，其它的都会等待，就能实现一个简单的悲观锁。
2. 用 Zookeeper 来做分布式锁，具体可以搜一下。
3. 自己实现，搞个节点来做这个事情，所有要获取锁的都走 RPC 调用来请求锁，用完以后记得释放，不然其他的节点就会挂那里。
Ⅵ JAVA多线程中“锁”的概念的理解
当有多个线程共用一种临界资源的时候，便会出现冲突，锁就是用来解决这种冲突的，跟上厕所一样，假如有ABC三个人都来上厕所而厕所只有一个一次只能进一人，A先来了，那么在A出来之前，这个厕所就处在了“锁”定状态，B和C憋死也要在外面等着，直到A出门（原因很多，如睡着了，方便完了，忘带厕纸了跑出来找人要....）“锁”定解除B和C才能进入，当然牛逼的进（A和B有一腿只让B进或者优先级高或者...），SB的在外面继续等。此乃吾理解之锁定，希望能够对你有所帮助
Ⅶ java集群下定时任务，怎么保证任务只执行一次啊
用redis分布式锁就可以搞定，因为redis对于集群是共享的
Ⅷ 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？行，怎样舒服怎样用吧，别重复代码就行。
Ⅸ java 集群
一旦在服务器上安装并运行了群集服务 ， 该服务器即可加入群集。群集化操作可以减少单点故障数量，并且实现了群集化资源的高可用性。下述各节简要介绍了群集创建和群集操作中的节点行为。
注意 ： 有关安装群集服务器的信息 ， 请参阅 Windows server 2003 产品家族的帮助和部署指南。
创建群集
在服务器群集产品中含有用来在服务器上安装群集软件和创建新群集的群集安装实用工具。创建新群集时，首先在选择作为群集的第一个成员的计算机上运行该实用工具。第一步是确定群集名称并创建群集数据库和初始的群集成员列表来定义新群集。 Windows server 2003 群集新增了一个群集管理设置向导以及使用 cluster.exe 命令行界面创建 （ 包括从远程创建 ） 群集的功能。
创建群集的第二步是 ， 添加可供所有群集成员使用的共用数据存储设备。这样，创建的新群集将带有一个节点、自己的本地数据存储设备以及群集共用资源 —— 通常是磁盘或数据存储和连接介质资源。
创建群集的最后一步是 ， 在另外将要成为群集成员的每一台计算机上运行安装实用工具。每当将新节点添加到群集中时，新节点都会自动从群集的原始成员获得现有群集数据库的副本。当节点加入或形成群集时，群集服务会更新该节点私有的配置数据库副本。
形成群集
如果服务器运行了群集服务并且无法找到群集中的其它节点 ， 它自己可以形成一个群集。要形成群集，节点必须能够获得对仲裁资源的独占权。
当最初形成群集时 ， 群集中的第一个节点将包括群集配置数据库。每当有新节点加入群集时，新节点都会在本地获得并保持群集配置数据库的副本。仲裁资源用恢复日志（其中含有同节点无关的群集配置和状态数据）的形式存储配置数据库的最新版本。
在群集运行中 ， 群集服务使用仲裁恢复日志执行以下操作 ：
• 保证只有一组活动、可相互通讯的节点才能形成群集
• 仅当某个节点可以获得对仲裁资源的控制权时 ， 才允许它形成群集
• 仅当某个节点可以同控制仲裁资源的节点通讯时 ， 才允许它加入或留在现有群集中
从群集中的其它节点和群集服务管理接口的角度看 ， 当形成群集时 ， 群集中的每个节点可能处于三种不同状态中的一种。事件处理器会记录这些状态，而事件日志管理器会将这些状态复制到群集的其它节点。群集服务状态包括：
• 脱机 。此时的节点不是完全有效的群集成员。该节点及其群集服务器可能在运行，也可能未运行。
• 联机 。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影响、维护心跳通讯，并可以拥有和运行资源组。
• 暂停 。此时的节点是完全有效的群集成员。它遵从群集数据库的更新、对仲裁算法施加自己的影响、维护心跳通讯，但它无法接受资源组。它只能支持它当前已拥有的那些资源组。之所以提供暂停状态，是为了允许执行某些维护。大多数服务器群集组件会将联机和暂停视为等价的状态。
加入群集
如果一个服务器要加入现有群集 ， 则它必须运行群集服务并且必须成功找到群集中的其它节点。在找到其它节点后，加入的服务器必须接受群集成员资格验证，并获得群集配置数据库的副本。
加入现有群集的过程开始于 Windows Server 2003 或 Windows 2000 Service Control Manager 在节点上启动群集服务之时。在启动过程中，群集服务会配置并装入该节点的本地数据设备。它并不会试图将共用的群集数据设备作为节点联机，因为现有群集可能正在使用这些设备。
为了查找其它节点 ， 会启动一个发现过程。当节点发现任何群集成员时，它将执行身份验证序列。第一个群集成员会对新加入者进行身份验证，并且在新服务器得到成功验证后返回成功状态。如果验证不成功（未能识别待加入节点的群集成员身份，或者它使用了无效的帐户密码），则加入群集的请求会被拒绝。
进行成功验证后 ， 首先联机的群集节点会检查加入节点上的配置数据库副本。如果该副本已过时，对加入服务器进行验证的群集节点会为加入的服务器发送该数据库的更新副本。刚加入群集的节点在收到复制的数据库后，可以用它查找共享资源并根据需要将它们联机。
脱离群集
当节点关闭或群集服务被停止时 ， 节点可能脱离群集。但当节点不执行群集操作（比如不向群集配置数据库提交更新）时，节点也可能被迫脱离（被逐出）群集。
如果节点根据预先的计划脱离群集 ， 它会向其它所有节点成员发送 ClusterExit 消息 ， 通知它们它将脱离群集。该节点不等待任何响应就会立即进行关闭资源和所有群集连接的操作。由于其余节点收到了退出消息，因此它们不会执行在节点意外失效或网络通讯停止时发生的重新分组过程以重新确立群集成员身份。
[ 本日：2 本周：2 本月：60 总浏览数：128 ] [返回上一页] [打 印] [收 藏]
上一篇文章：故障检测和相关链接
下一篇文章：windows 2000活动目录详解之安装配置篇
Ⅹ Java多线程加锁的问题
publicclassTest{
publicstaticvoidmain(String[]args)throwsInterruptedException{
System.out.println("2个线程开始执行....");
TestHellohello1=newTestHello("A",1000);
TestHellohello2=newTestHello("B",2000);
Threaddemo1=newThread(hello1);
Threaddemo2=newThread(hello2);
demo1.start();
demo2.start();
try{
demo1.join();
demo2.join();
}finally{
System.out.println("线程均执行完成....");
}
}
}
{
privateStringworkname;
privateintworktime;
//省略workname和worktime的set和get方法
publicTestHello(Stringworkname,intworktime){
super();
this.workname=workname;
this.worktime=worktime;
}
publicvoidrun(){
for(inti=0;i<5;i++){
System.out.println(this.workname+"运行"+i);
try{
Thread.sleep(worktime);
}catch(InterruptedExceptione){
e.printStackTrace();
}
}
}
}