文档章节

java并发编程

 小鱼吃大鱼
发布于 2017/03/14 15:27
字数 1643
阅读 15
收藏 2

并发编程问题:

1、synchronized和lock区别,lock的condition
2、同步工具(Semaphores、CountDownLatch、CyclicBarrier等)
3、并发集合,如ConcurrentHashMap的实现原理,如果读写操作落到底层的同一个map上是如何处理的?
4、原子类,如AtomicLong的incrementAndGet方法内部实现原理(当时没回答上来)
5、volatile的实现原理

一、synchronized关键字 首先要分清 类对象和实例对象,对应的为类锁和对象锁。 类对象:静态方法 或 静态代码块 同步在类对象 (this.class) 对象锁:实例方法或 方法代码块 同步在实例对象上(new)

注:无论sychronized 加在方法还是对象上,他所取得的锁都是 对象

https://my.oschina.net/leejun2005/blog/483999](http://)

二、lock关键字

Java在过去很长一段时间只能通过synchronized关键字来实现互斥,它有一些缺点。比如你不能 扩展锁之外的方法或者块边界,尝试获取锁时不能中途取消等。Java 5 通过Lock接口提供了更复杂 的控制来解决这些问题。 ReentrantLock 类实现了 Lock,它拥有与 synchronized 相同的并发性和内 存语义且它还具有可扩展性。

**synchronized是在JVM层面实现的,因此系统可以监控锁的释放与否,而ReentrantLock使用代码实现的,系统无法自动释放锁,需要在代码中finally子句中显式释放锁lock.unlock();

在并发量比较小的情况下,使用synchronized是个不错的选择,但是在并发量比较高的情况下,其性能下降很严重,此时ReentrantLock是个不错的方案。

ReentrantLock 类(重入锁)实现了 Lock ,它拥有与 synchronized相同的并发性和内存语义,但是添加了类似锁投piao、定时锁等候和可中断锁等候的一些特性。此外,它还提供了在激烈争用情况下更佳的性能。(换句话说,当许多线程都想访问共享资源时,JVM 可以花更少的时候来调度线程,把更多时间用在执行线程上。) **

http://blog.csdn.net/lingzhm/article/details/44947015

lock 的condition

http://blog.csdn.net/vking_wang/article/details/9952063

三、同步工具

http://www.cnblogs.com/whgw/archive/2011/09/29/2195555.html

http://blog.csdn.net/dlf123321/article/details/51382503

四、并发集合

HashTable容器使用synchronized来保证线程安全,但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时,其他线程访问HashTable的同步方法时,可能会进入阻塞或轮询状态。如线程1使用put进行添加元素,线程2不但不能使用put方法添加元素,并且也不能使用get方法来获取元素,所以竞争越激烈效率越低。 ConcurrentHashMap的锁分段技术

HashTable容器在竞争激烈的并发环境下表现出效率低下的原因,是因为所有访问HashTable的线程都 必须竞争同一把锁,那假如容器里有多把锁,每一把锁用于锁容器其中一部分数据,那么当多线程访问 容器里不同数据段的数据时,线程间就不会存在锁竞争,从而可以有效的提高并发访问效率,这就是ConcurrentHashMap所使用的锁分段技术,首先将数据分成一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他线程访问。

http://blog.csdn.net/qq_27093465/article/details/52279473

注:hash table虽然性能上不如ConcurrentHashMap,但并不能完全被取代,两者的迭代器的一致性不同的,hash table的迭代器是强一致性的,而concurrenthashmap是弱一致的。 ConcurrentHashMap的get,clear,iterator 都是弱一致性的。 Doug Lea 也将这个判断留给用户自己决定是否使用ConcurrentHashMap。

五、volatile

在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中,或者为常量时,不必使用。

在当前的Java内存模型下,线程可以把变量保存在本地内存(比如机器的寄存器)中,而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值,而另外一个线程还继续使用它在寄存器中的变量值的拷贝,造成数据的不一致。

要解决这个问题,只需要像在本程序中的这样,把该变量声明为volatile(不稳定的)即可,这就指示JVM,这个变量是不稳定的,每次使用它都到主存中进行读取。一般说来,多任务环境下各任务间共享的标志都应该加volatile修饰。

Volatile修饰的成员变量在每次被线程访问时,都强迫从共享内存中重读该成员变量的值。而且,当成员变量发生变化时,强迫线程将变化值回写到共享内存。这样在任何时刻,两个不同的线程总是看到某个成员变量的同一个值。

1) 变量的修改对所有线程可见

理解:

 ** 线程中每次use变量时,都需要连续执行read->load->use几项操作,即所谓的每次使用都要从主内存更新变量值,这样其它线程的修改对该线程就是可见的。

  线程每次assign变量时,都需要连续执行assign->store->write几项操作,即所谓每次更新完后都会回写到主内存,这样使得其它线程读到的都是最新数据。**

2)禁止指令重排

http://blog.csdn.net/feier7501/article/details/20001083

** 对于非volatile修饰的变量,尽管jvm的优化,会导致变量的可见性问题,但这种可见性的问题也只是在短时间内高并发的情况下发生,CPU执行时会很快刷新Cache,一般的情况下很难出现,而且出现这种问题是不可预测的,与jvm, 机器配置环境等都有关。**

volatile 与static的区别:

static 只是声明变量在主存上的唯一性,不能保证工作区与主存区变量值的一致性;除非变量的值是不可变的,即再加上final的修饰符,否则static声明的变量,不是线程安全的。

http://blog.sina.com.cn/s/blog_4e1e357d0101i486.html

© 著作权归作者所有

粉丝 4
博文 63
码字总数 32511
作品 0
合肥
私信 提问

暂无文章

nproc systemd on CentOS 7

Increasing nproc for processes launched by systemd on CentOS 7 Ask Question I have successfully increased the nofile and nproc value for the local users, but I couldn't find a p......

MtrS
45分钟前
3
0
了解微信小程序下拉刷新功能

小程序提供了这个事件。 onPullDownRefresh() 监听用户下拉刷新事件。 如果要开启下拉刷新功能,要先到json配置: "enablePullDownRefresh":true 配置后下拉有反应了但是没有加载效果,在onP...

oixxan__
今天
2
0
springmvc java对象转json,上传下载(未完)拦截器Interceptor以及源码解析(未完待续)

package com.atguigu.my.controller;import java.util.Collection;import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Contr......

architect刘源源
今天
29
0
[日更-2019.5.24、25、26] Android系统中的Binder通信机制分析(一)--servicemanager

声明 其实对于Android系统Binder通信的机制早就有分析的想法,记得去年6、7月份Mr.Deng离职期间约定一起对其进行研究的,但因为我个人问题没能实施这个计划,留下些许遗憾... 最近,刚好在做...

Captain_小馬佩德罗
昨天
24
0
聊聊dubbo的DataStore

序 本文主要研究一下dubbo的DataStore DataStore dubbo-2.7.2/dubbo-common/src/main/java/org/apache/dubbo/common/store/DataStore.java @SPI("simple")public interface DataStore { ......

go4it
昨天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部