lock

异常:Attempted to lock an already-locked dir svn:

六眼飞鱼酱① 提交于 2019-12-05 06:22:30
今天用myeclipse上svn更新代码发现报一个异常: Attempted to lock an already-locked dir svn: Working copy 'D:\xxxx\xxxx-webapp' locked 很明显都知道路径: D:\xxxx\xxxx-webapp 锁着了 找到 D:\xxxx\右键 操作如图 然后从新启动tomcat 就ok了!!!!! 来源: oschina 链接: https://my.oschina.net/u/152736/blog/94168

Java线程:条件变量 lock

天涯浪子 提交于 2019-12-04 18:29:27
条件变量是Java5线程中很重要的一个概念,顾名思义,条件变量就是表示条件的一种变量。但是必须说明,这里的条件是没有实际含义的,仅仅是个标记而已,并且条件的含义往往通过代码来赋予其含义。 这里的条件和普通意义上的条件表达式有着天壤之别。条件变量都实现了java.util.concurrent.locks.Condition接口,条件变量的实例化是通过一个Lock对象上调用newCondition()方法来获取的,这样,条件就和一个锁对象绑定起来了。因此,Java中的条件变量只能和锁配合使用,来控制并发程序访问竞争资源的安全。 条件变量的出现是为了更精细控制线程等待与唤醒,在Java5之前,线程的等待与唤醒依靠的是Object对象的wait()和notify()/notifyAll()方法,这样的处理不够精细。 而在Java5中,一个锁可以有多个条件,每个条件上可以有多个线程等待,通过调用await()方法,可以让线程在该条件下等待。当调用signalAll()方法,又可以唤醒该条件下的等待的线程。有关Condition接口的API可以具体参考JavaAPI文档。 条件变量比较抽象,原因是他不是自然语言中的条件概念,而是程序控制的一种手段。 下面以一个银行存取款的模拟程序为例来揭盖Java多线程条件变量的神秘面纱: 有一个账户,多个用户(线程)在同时操作这个账户,有的存款有的取款

Java多线程(十)之ReentrantReadWriteLock深入分析

丶灬走出姿态 提交于 2019-12-03 09:14:08
一、ReentrantReadWriteLock与ReentrantLock 说到ReentrantReadWriteLock,首先要做的是与ReentrantLock划清界限。它和后者都是单独的实现,彼此之间没有继承或实现的关系。 ReentrantLock 实现了标准的互斥操作,也就是一次只能有一个线程持有锁,也即所谓独占锁的概念。前面的章节中一直在强调这个特点。显然这个特点在一定程度上面减低了吞吐量,实际上独占锁是一种保守的锁策略,在这种情况下任何“读/读”,“写/读”,“写/写”操作都不能同时发生。但是同样需要强调的一个概念是,锁是有一定的开销的,当并发比较大的时候,锁的开销就比较客观了。所以如果可能的话就尽量少用锁,非要用锁的话就尝试看能否改造为读写锁。 ReadWriteLock 描述的是:一个资源能够被多个读线程访问,或者被一个写线程访问,但是不能同时存在读写线程。也就是说读写锁使用的场合是一个共享资源被大量读取操作,而只有少量的写操作(修改数据)。清单0描述了ReadWriteLock的API。 清单0 ReadWriteLock 接口 [java] view plain copy public interface ReadWriteLock { Lock readLock(); Lock writeLock(); } 清单0描述的ReadWriteLock结构

对BOOST 中同步互斥的一些理解

只谈情不闲聊 提交于 2019-12-03 05:56:02
对BOOST 中同步互斥的一些理解 首先,BOOST中有4种有关互斥量得概念。 1.LOCKABLE :仅支持排它型所有权 2.TIMEDLOCKABLE:支持带超时的排它型所有权 3.SHAREDLOCKABLE: 支持带超时的排他型所有权和共享型所有权(读写锁) 4.UPGRADELOCKABLE: 支持带超时的排他型所有权和共享型所有权,以及共享型所有权升级为排他型所有权(升级过程阻塞)(也支持降级) 可以看到2强化自1,3强化自2.4强化自3,支持某一概念则一定支持其强化自的概念。 boost::mutex 实现了LOCKABLE概念 (boost::recursive_mutex 是其递归锁的版本) boost::timed_mutex 实现了TIMEDLOCKABLE概念 (boost::recursive_timed_mutex 是其递归锁的版本) boost::shared_mutex实现了SHAREDLOCKABLE概念 boost::shared_mutex同样实现了UPGRADELOCKABLE概念 出于提供RAII操作风格和安全等其他一些原因BOOST不希望用户直接调用各种MUTEX类型中的相关接口,而是通过它提供的一些LOCK_TYPE来帮助我们调用。 主要的LOCK_TYPE包括: boost::unique_lock<LOCKABLE>

Java 复习 —— 锁以及线程之间的通讯

时光总嘲笑我的痴心妄想 提交于 2019-12-03 05:54:59
1、Lock 1)1.5版本之后出现,java.util.concurrent.locks.Lock 2) Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构,可以具有差别很大的属性,可以支持多个相关的 Condition 对象。 锁是控制多个线程对共享资源进行访问的工具。通常,锁提供了对共享资源的独占访问。一次只能有一个线程获得锁,对共享资源的所有访问都需要首先获得锁。不过,某些锁可能允许对共享资源并发访问,如 ReadWriteLock 的读取锁。 3)一般使用的Lock替代synchronized的代码如下: private Lock l = new ReentrantLock(); l.lock(); try { // access the resource protected by this lock } finally { l.unlock(); } 4)和synchronized一样,也可以在线程之间进行通讯,如下代码: class Data { private int number = 0;// 共享变量 private Lock lock = new ReentrantLock(); // 一种互斥锁 private Condition c1 = lock.newCondition(); //

java并发编程

吃可爱长大的小学妹 提交于 2019-12-03 05:54:22
1. ReentrantLock拥有与Synchronized相同的并发性和内存语义,此外还多了 锁投票,定时锁等候和中断锁等候。 线程A和B都要获取对象O的锁定,假设A获取了对象O锁,B将等待A释放对O的锁定, 如果使用 synchronized ,如果A不释放,B将一直等下去,不能被中断 如果 使用ReentrantLock,如果A不释放,可以使B在等待了足够长的时间以后,中断等待,而干别的事情 ReentrantLock获取锁定有三种方式: a) lock() , 如果获取了锁立即返回,如果别的线程持有锁,当前线程则一直处于休眠状态,直到获取锁 b) tryLock() , 如果获取了锁立即返回true,如果别的线程正持有锁,立即返回false; c) tryLock(long timeout, TimeUnit unit) , 如果获取了锁定立即返回true,如果别的线程正持有锁,会等待参数给定的时间,在等待的过程中,如果获取了锁定,就返回true,如果等待超时,返回false; d) lockInterruptibly :如果获取了锁定立即返回,如果没有获取锁定,当前线程处于休眠状态,直到或者锁定,或者当前线程被别的线程中断 2. synchronized是在JVM层面上实现的,不但可以通过一些监控工具监控synchronized的锁定,而且在代码执行时出现异常

解决svn working copy locked问题

萝らか妹 提交于 2019-12-03 03:22:29
标题:working copy locked 提示:your working copy appears to be locked. run cleanup to amend the situation. 产生这种情况大多是因为上次svn命令执行失败且被锁定了。 如果cleanup没有效果的话只好手动删除锁定文件。 cd 到svn项目目录下,然后执行如下命令 del lock /q/s 就把锁删掉了。 附图: 来源: oschina 链接: https://my.oschina.net/u/129830/blog/53255

深入理解ReentrantLock

江枫思渺然 提交于 2019-12-02 08:31:31
在Java中通常实现锁有两种方式,一种是synchronized关键字,另一种是Lock。二者其实并没有什么必然联系,但是各有各的特点,在使用中可以进行取舍的使用。首先我们先对比下两者。 实现: 首先最大的不同:synchronized是基于JVM层面实现的,而Lock是基于JDK层面实现的。曾经反复的找过synchronized的实现,可惜最终无果。但Lock却是基于JDK实现的,我们可以通过阅读JDK的源码来理解Lock的实现。 使用: 对于使用者的直观体验上Lock是比较复杂的,需要lock和realse,如果忘记释放锁就会产生死锁的问题,所以,通常需要在finally中进行锁的释放。但是synchronized的使用十分简单,只需要对自己的方法或者关注的同步对象或类使用synchronized关键字即可。但是对于锁的粒度控制比较粗,同时对于实现一些锁的状态的转移比较困难。例如: 特点: tips synchronized Lock 锁获取超时 不支持 支持 获取锁响应中断 不支持 支持 优化: 在JDK1.5之后synchronized引入了偏向锁,轻量级锁和重量级锁,从而大大的提高了synchronized的性能,同时对于synchronized的优化也在继续进行。期待有一天能更简单的使用java的锁。 在以前不了解Lock的时候,感觉Lock使用实在是太复杂

Inside AbstractQueuedSynchronizer (4)

情到浓时终转凉″ 提交于 2019-12-02 08:31:02
3.6 ConditionObject AbstractQueuedSynchronizer的内部类ConditionObject实现了Condition接口。Condition接口提供了跟Java语言内置的monitor机制类似的接口:await()/signal()/signalAll(),以及一些支持超时和回退的await版本。可以将任意个数的ConcitionObject关联到对应的synchronizer,例如通过调用ReentrantLock.newCondition()方法即可构造一个ConditionObject实例。每个ConditionObject实例内部都维护一个ConditionQueue,该队列的元素跟AbstractQueuedSynchronizer的WaitQueue一样,都是Node对象。 ConditionObject的await()代码如下: Java代码 public final void await() throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); Node node = addConditionWaiter(); int savedState = fullyRelease(node); int

ubuntu12.04--无法获得锁 /var/lib/dpkg/lock

断了今生、忘了曾经 提交于 2019-11-29 15:49:40
结果终端提示: 无法获得锁 /var/lib/dpkg/lock - open (11: 资源暂时不可用) E: 无法锁定管理目录(/var/lib/dpkg/),是否有其他进程正占用它?” 解决办法如下: 1.终端输入 ps -aux ,列出进程,找到含有apt-get的进程,直接sudo kill PID解决。 2.强制解锁--命令: sudo rm /var/cache/apt/archives/lock sudo rm /var/lib/dpkg/lock 解释: “dpkg ”是“Debian Package ”的简写。为 “Debian” 专门开发的套件管理系统,方便 软件 的安装、更新及移除。所有源自“Debian”的“Linux ”发行版都使用 “dpkg”,例如 “Ubuntu”、“Knoppix ”等。 dpkg是 Debian 软件包管理器的基础,它被伊恩·默多克创建于1993年。dpkg与 RPM 十分相似,同样被用于安装、卸载和供给.deb软件包相关的信息。   dpkg本身是一个底层的工具。上层的工具,如 APT ,被用于从远程获取软件包以及处理复杂的软件包关系。 “dpkg”是“Debian Package”的简写。 来源: oschina 链接: https://my.oschina.net/u/200838/blog/88358