- 浏览: 189289 次
- 性别:
- 来自: 武汉
文章分类
最新评论
-
shuaijie506:
以前有点疑惑,现在终于明白了,线程安全是没问题的,想想也是,如 ...
jsp自定义标签 线程安全 -
Laster2800:
原来如此,想不到传统的标记处理器也是线程安全的,受教了。
jsp自定义标签 线程安全 -
GoingForward:
这篇文章是不是可以浓缩为下面几点:1.在非静态内部类中不可以声 ...
static class -
wellse:
呵呵,就是这样!!要的就是这个效果
jsp自定义标签 线程安全 -
xiaohuafyle:
JNDI
Jakob has done a great series on Java Concurrency - check out the first 14 articles at his blog. Going forward, we're delighted to announce that you'll also be able to follow the series here on JavaLobby.
A read / write lock is more sophisticated lock than the Lock implementations shown in the text Locks in Java. Imagine you have an application that reads and writes some resource, but writing it is not done as much as reading it is. Two threads reading the same resource does not cause problems for each other, so multiple threads that want to read the resource are granted access at the same time, overlapping. But, if a single thread wants to write to the resource, no other reads nor writes must be in progress at the same time. To solve this problem of allowing multiple readers but only one writer, you will need a read / write lock.
Java 5 comes with read / write lock implementations in the java.util.concurrent package. Even so, it may still be useful to know the theory behind their implementation.
Here is a list of the topics covered in this text:
Read / Write Lock Java Implementation
Read / Write Lock Reentrance
Read Reentrance
Write Reentrance
Read to Write Reentrance
Write to Read Reentrance
Fully Reentrant Java Implementation
Calling unlock() from a finally-clause
Read / Write Lock Java Implementation
First let's summarize the conditions for getting read and write access to the resource:
Read Access If no threads are writing, and no threads have requested write access.
Write Access If no threads are reading or writing.
If a thread wants to read the resource, it is okay as long as no threads are writing to it, and no threads have requested write access to the resource. By up-prioritizing write-access requests we assume that write requests are more important than read-requests. Besides, if reads are what happens most often, and we did not up-prioritize writes, starvation could occur. Threads requesting write access would be blocked until all readers had unlocked the ReadWriteLock. If new threads were constantly granted read access the thread waiting for write access would remain blocked indefinately, resulting in starvation. Therefore a thread can only be granted read access if no thread has currently locked the ReadWriteLock for writing, or requested it locked for writing.
A thread that wants write access to the resource can be granted so when no threads are reading nor writing to the resource. It doesn't matter how many threads have requested write access or in what sequence, unless you want to guarantee fairness between threads requesting write access.
With these simple rules in mind we can implement a ReadWriteLock as shown below:
view sourceprint?01.public class ReadWriteLock{
02.
private int readers = 0;
03.
private int writers = 0;
04.
private int writeRequests = 0;
05.
public synchronized void lockRead() throws InterruptedException{
06.
while(writers > 0 || writeRequests > 0){
07.
wait();
08.
}
09.
readers++;
10.
}
11.
public synchronized void unlockRead(){
12.
readers--;
13.
notifyAll();
14.
}
15.
public synchronized void lockWrite() throws InterruptedException{
16.
writeRequests++;
17.
while(readers > 0 || writers > 0){
18.
wait();
19.
}
20.
writeRequests--;
21.
writers++;
22.
}
23.
public synchronized void unlockWrite() throws InterruptedException{
24.
writers--;
25.
notifyAll();
26.
}
27.}
The ReadWriteLock has two lock methods and two unlock methods. One lock and unlock method for read access and one lock and unlock for write access.
The rules for read access are implemented in the lockRead() method. All threads get read access unless there is a thread with write access, or one or more threads have requested write access.
The rules for write access are implemented in the lockWrite() method. A thread that wants write access starts out by requesting write access (writeRequests++). Then it will check if it can actually get write access. A thread can get write access if there are no threads with read access to the resource, and no threads with write access to the resource. How many threads have requested write access doesn't matter.
It is worth noting that both unlockRead() and unlockWrite() calls notifyAll() rather than notify(). To explain why that is, imagine the following situation:
Inside the ReadWriteLock there are threads waiting for read access, and threads waiting for write access. If a thread awakened by notify() was a read access thread, it would be put back to waiting because there are threads waiting for write access. However, none of the threads awaiting write access are awakened, so nothing more happens. No threads gain neither read nor write access. By calling noftifyAll() all waiting threads are awakened and check if they can get the desired access.
Calling notifyAll() also has another advantage. If multiple threads are waiting for read access and none for write access, and unlockWrite() is called, all threads waiting for read access are granted read access at once - not one by one.
Read / Write Lock Reentrance
The ReadWriteLock class shown earlier is not reentrant. If a thread that has write access requests it again, it will block because there is already one writer - itself. Furthermore, consider this case:
Thread 1 gets read access.
Thread 2 requests write access but is blocked because there is one reader.
Thread 1 re-requests read access (re-enters the lock), but is blocked because there is a write request
In this situation the previous ReadWriteLock would lock up - a situation similar to deadlock. No threads requesting neither read nor write access would be granted so.
To make the ReadWriteLock reentrant it is necessary to make a few changes. Reentrance for readers and writers will be dealt with separately.
A read / write lock is more sophisticated lock than the Lock implementations shown in the text Locks in Java. Imagine you have an application that reads and writes some resource, but writing it is not done as much as reading it is. Two threads reading the same resource does not cause problems for each other, so multiple threads that want to read the resource are granted access at the same time, overlapping. But, if a single thread wants to write to the resource, no other reads nor writes must be in progress at the same time. To solve this problem of allowing multiple readers but only one writer, you will need a read / write lock.
Java 5 comes with read / write lock implementations in the java.util.concurrent package. Even so, it may still be useful to know the theory behind their implementation.
Here is a list of the topics covered in this text:
Read / Write Lock Java Implementation
Read / Write Lock Reentrance
Read Reentrance
Write Reentrance
Read to Write Reentrance
Write to Read Reentrance
Fully Reentrant Java Implementation
Calling unlock() from a finally-clause
Read / Write Lock Java Implementation
First let's summarize the conditions for getting read and write access to the resource:
Read Access If no threads are writing, and no threads have requested write access.
Write Access If no threads are reading or writing.
If a thread wants to read the resource, it is okay as long as no threads are writing to it, and no threads have requested write access to the resource. By up-prioritizing write-access requests we assume that write requests are more important than read-requests. Besides, if reads are what happens most often, and we did not up-prioritize writes, starvation could occur. Threads requesting write access would be blocked until all readers had unlocked the ReadWriteLock. If new threads were constantly granted read access the thread waiting for write access would remain blocked indefinately, resulting in starvation. Therefore a thread can only be granted read access if no thread has currently locked the ReadWriteLock for writing, or requested it locked for writing.
A thread that wants write access to the resource can be granted so when no threads are reading nor writing to the resource. It doesn't matter how many threads have requested write access or in what sequence, unless you want to guarantee fairness between threads requesting write access.
With these simple rules in mind we can implement a ReadWriteLock as shown below:
view sourceprint?01.public class ReadWriteLock{
02.
private int readers = 0;
03.
private int writers = 0;
04.
private int writeRequests = 0;
05.
public synchronized void lockRead() throws InterruptedException{
06.
while(writers > 0 || writeRequests > 0){
07.
wait();
08.
}
09.
readers++;
10.
}
11.
public synchronized void unlockRead(){
12.
readers--;
13.
notifyAll();
14.
}
15.
public synchronized void lockWrite() throws InterruptedException{
16.
writeRequests++;
17.
while(readers > 0 || writers > 0){
18.
wait();
19.
}
20.
writeRequests--;
21.
writers++;
22.
}
23.
public synchronized void unlockWrite() throws InterruptedException{
24.
writers--;
25.
notifyAll();
26.
}
27.}
The ReadWriteLock has two lock methods and two unlock methods. One lock and unlock method for read access and one lock and unlock for write access.
The rules for read access are implemented in the lockRead() method. All threads get read access unless there is a thread with write access, or one or more threads have requested write access.
The rules for write access are implemented in the lockWrite() method. A thread that wants write access starts out by requesting write access (writeRequests++). Then it will check if it can actually get write access. A thread can get write access if there are no threads with read access to the resource, and no threads with write access to the resource. How many threads have requested write access doesn't matter.
It is worth noting that both unlockRead() and unlockWrite() calls notifyAll() rather than notify(). To explain why that is, imagine the following situation:
Inside the ReadWriteLock there are threads waiting for read access, and threads waiting for write access. If a thread awakened by notify() was a read access thread, it would be put back to waiting because there are threads waiting for write access. However, none of the threads awaiting write access are awakened, so nothing more happens. No threads gain neither read nor write access. By calling noftifyAll() all waiting threads are awakened and check if they can get the desired access.
Calling notifyAll() also has another advantage. If multiple threads are waiting for read access and none for write access, and unlockWrite() is called, all threads waiting for read access are granted read access at once - not one by one.
Read / Write Lock Reentrance
The ReadWriteLock class shown earlier is not reentrant. If a thread that has write access requests it again, it will block because there is already one writer - itself. Furthermore, consider this case:
Thread 1 gets read access.
Thread 2 requests write access but is blocked because there is one reader.
Thread 1 re-requests read access (re-enters the lock), but is blocked because there is a write request
In this situation the previous ReadWriteLock would lock up - a situation similar to deadlock. No threads requesting neither read nor write access would be granted so.
To make the ReadWriteLock reentrant it is necessary to make a few changes. Reentrance for readers and writers will be dealt with separately.
发表评论
-
Jetty例子
2010-11-07 22:04 1488import java.io.IOException; ... -
排序面试算法
2010-09-08 08:43 1604从大学到现在,参加过很多面试,经常会被问到一些基本的算法题, ... -
IReport一些注意
2010-09-05 22:02 1316用的是 Ireport2.0版本 更高版本可能没有这个问题 ... -
jsp自定义标签 线程安全
2010-08-28 14:21 3957我们在编写自定义标签的时候设置属性如下 public cl ... -
[转]Java类加载原理解析
2009-11-04 21:47 1161转载 Java 类加载原理解析 ... -
线程上下文类加载器
2009-11-04 21:46 5551线程上下文类加载器 问题:何时使用Thread. ... -
JDBC Sybase
2009-11-04 21:02 4014import java.sql.Connection; im ... -
JDK 5.0 泛型 动态参数 枚举
2009-11-04 21:02 3058import java.util.ArrayList;impo ... -
再看heap 和stack,还有多了解内存
2009-11-03 16:28 1164heap 1.堆石一个“运行时”数据区,类实例化的对象就是从 ... -
java中读取Properties文件
2009-10-23 12:58 1540java 中读取Properties 文 ... -
JNI
2009-10-22 22:15 1420... -
Hibernate经典文章
2009-10-19 12:37 922Lazy Loading (Load&Get) ... -
JNDI
2009-10-15 14:15 2633最近写书,写到JNDI,到处查资料,发现所有的中文资料都对JN ... -
JDBC连接各种数据库
2009-10-14 10:13 937常用JDBC连接数据库方法总结如下: 一、DB2 Cl ... -
java并发的一些题目
2009-09-24 23:41 989a 回答 结果又一下 几种情况 execute here Ca ... -
static class
2009-08-19 14:55 18129在一个类中创建另外 ... -
C++ 对象参数传递
2009-08-07 12:08 1652#include<iostream.h> cla ... -
递归与间接递归
2009-08-07 11:02 48811. 介绍 递归技术允许 ... -
concurrent lib的学习
2009-07-13 17:51 9811.关于BlockingQueue的学习,这是一个阻塞的队列, ... -
应该看的书籍
2009-07-12 21:33 9301.代码大全 2.人月神话 3.设计模式 4.网格计算 ...
相关推荐
java_concurrency_in_practice.pdf jcip-examples-src.jar jcip-annotations-src.jar 英文版是高清晰的,实战和实践都是同一帮人对英文版书的翻译,网传实战的翻译质量更好,实战是2012年出版的,应该是对前一版实践...
Concurrency: 213.42 //实际最高并发数 Successful transactions: 2564081 //成功处理次数 Failed transactions: 11 //失败处理次数 Longest transaction: 29.04 //每次传输所花最长时间 Shortest transaction: 0.00...
《Java 7 Concurrency Cookbook》教程及代码。 《Java 7 Concurrency Cookbook》这本书不错,每节一个实例。 《Java Concurrency in Practice》这本书理论比较多,有点难懂,适合高级水平吧。 Book review: ...
NULL 博文链接:https://iintothewind.iteye.com/blog/2081391
博文链接:https://projector.iteye.com/blog/209730
concurrency:Java Concurrency in Practice源代码
Java Concurrency in Practice 英文无水印pdf pdf所有页面使用FoxitReader和PDF-XChangeViewer测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者...
并行编程,经典之作: 免费大餐不久就将结束。对此,你有何打算,做好下一步准备了么?
The Art of Concurrency: A Thread Monkey's Guide to Writing Parallel Applications PDF文件,很清晰,,, Intel资深工程师分享并发编程知识及内幕技术 详述如何在各种算法中使用线程化方法 开发并行代码算法...
不管你是新程序员还是...注:本文档根据http://www.importnew.com/12773.html 和http://ifeve.com/java-multi-threading-concurrency-interview-questions-with-answers/ 这两个网站的并发编程试题集整理得到的文档,
Java Concurrency in practice
java8 源码 Java 并发多线程从简到全 参考: 目录: [TOC] 相关文档: kwseeker/netty Executors线程池.md 1 基本概念 1.1 CPU与线程的关系 1.2 线程与进程的区别和关系 1.3 吞吐量 1.4 线程安全 1.5 线程声明周期 ...
NULL 博文链接:https://silverend.iteye.com/blog/2094702
<<java并行编程>>英文版chm格式,英文名称<Java Concurrency in Practice>,一直想买这本书,但总是缺货,找到了电子版,分享给大家。 Java Concurrency in Practice By Brian Goetz, Tim Peierls, Joshua Bloch,...
NULL 博文链接:https://xpenxpen.iteye.com/blog/899004
java concurrency in practice
Java Concurrency Programming Lessons.
Java concurrency in Practice高清pdf,带目录标签,Java并发实战