lock

今天用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

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

一、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 中同步互斥的一些理解 首先，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>

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(); //

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的锁定，而且在代码执行时出现异常

标题: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

在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使用实在是太复杂

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

结果终端提示: 无法获得锁 /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