标签归档:面试

Java Synchronize 和 Lock 的区别与用法

在分布式开发中,锁是线程控制的重要途径。Java为此也提供了2种锁机制,synchronized和lock。做为Java爱好者,自然少不了对比一下这2种机制,也能从中学到些分布式开发需要注意的地方。

我们先从最简单的入手,逐步分析这2种的区别。

一、synchronized和lock的用法区别

synchronized:在需要同步的对象中加入此控制,synchronized可以加在方法上,也可以加在特定代码块中,括号中表示需要锁的对象。
lock:需要显示指定起始位置和终止位置。一般使用ReentrantLock类做为锁,多个线程中必须要使用一个ReentrantLock类做为对象才能保证锁的生效。且在加锁和解锁处需要通过lock()和unlock()显示指出。所以一般会在finally块中写unlock()以防死锁。
用法区别比较简单,这里不赘述了,如果不懂的可以看看Java基本语法。

二、synchronized和lock性能区别

synchronized是托管给JVM执行的,而lock是java写的控制锁的代码。在Java1.5中,synchronize是性能低效的。因为这是一个重量级操作,需要调用操作接口,导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象,性能更高一些。但是到了Java1.6,发生了变化。synchronize在语义上很清晰,可以进行很多优化,有适应自旋,锁消除,锁粗化,轻量级锁,偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示,他们也更支持synchronize,在未来的版本中还有优化余地。
说到这里,还是想提一下这2中机制的具体区别。据我所知,synchronized原始采用的是CPU悲观锁机制,即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。而在CPU转换线程阻塞时会引起线程上下文切换,当有很多线程竞争锁的时候,会引起CPU频繁的上下文切换导致效率很低。
而Lock用的是乐观锁方式。所谓乐观锁就是,每次不加锁而是假设没有冲突而去完成某项操作,如果因为冲突失败就重试,直到成功为止。乐观锁实现的机制就是CAS操作(Compare and Swap)。我们可以进一步研究ReentrantLock的源代码,会发现其中比较重要的获得锁的一个方法是compareAndSetState。这里其实就是调用的CPU提供的特殊指令。
现代的CPU提供了指令,可以自动更新共享数据,而且能够检测到其他线程的干扰,而 compareAndSet() 就用这些代替了锁定。这个算法称作非阻塞算法,意思是一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。
我也只是了解到这一步,具体到CPU的算法如果感兴趣的读者还可以在查阅下,如果有更好的解释也可以给我留言,我也学习下。

三、synchronized和lock用途区别

synchronized原语和ReentrantLock在一般情况下没有什么区别,但是在非常复杂的同步应用中,请考虑使用ReentrantLock,特别是遇到下面2种需求的时候。
1.某个线程在等待一个锁的控制权的这段时间需要中断
2.需要分开处理一些wait-notify,ReentrantLock里面的Condition应用,能够控制notify哪个线程
3.具有公平锁功能,每个到来的线程都将排队等候

四、synchronized和Lock的区别
相同点:
ReentrantLock(可重入互斥锁),它具有与使用 synchronized方法和语句所访问的隐式监视器锁相同的一些基本行为和语义,但功能更强大。
不同点:
a、ReentrantLock多了锁投票,定时锁等候,中断锁等候;synchronized锁不能被打断;
b、synchronized是在JVM层面上实现的,不但可以通过一些监控工具监控synchronized的锁定,而且在代码执行时出现异常,JVM会自动释放锁定;但是使用Lock则不行,lock是通过代码实现的,要保证锁定一定会被释放,就必须将unLock()放到finally{}中;
c、在资源竞争不是很激烈的情况下,Synchronized的性能要优于ReetrantLock,但是在资源竞争很激烈的情况下,Synchronized的性能会下降几十倍;但是ReetrantLock的性能能维持常态;
d、Atomic,不激烈情况下,性能比synchronized略逊,而激烈的时候,也能维持常态。激烈的时候,Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点,就是只能同步一个值,一段代码中只能出现一个Atomic的变量,多于一个同步无效。因为他不能在多个Atomic之间同步。
线程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:如果获取了锁定立即返回,如果没有获取锁定,当前线程处于休眠状态,直到或者锁定,或者当前线程被别的线程中断。

参考:http://blog.csdn.net/natian306/article/details/18504111
http://f.dataguru.cn/thread-672673-1-1.html

深入解析HashMap、HashTable

Java集合类是个非常重要的知识点,HashMap、HashTable、ConcurrentHashMap等算是集合类中的重点,可谓“重中之重”,首先来看个问题,如面试官问你:HashMap和HashTable有什么区别,一个比较简单的回答是:
1、HashMap是非线程安全的,HashTable是线程安全的。
2、HashMap的键和值都允许有null值存在,而HashTable则不行。
3、因为线程安全的问题,HashMap效率比HashTable的要高。
能答出上面的三点,简单的面试,算是过了,但是如果再问:Java中的另一个线程安全的与HashMap及其类似的类是什么?同样是线程安全,它与HashTable在线程同步上有什么不同?能把第二个问题完整的答出来,说明你的基础算是不错的了.
一、HashMap的内部存储结构
Java中数据存储方式最底层的两种结构,一种是数组,另一种就是链表,数组的特点:连续空间,寻址迅速,但是在删除或者添加元素的时候需要有较大幅度的移动,所以查询速度快,增删较慢。而链表正好相反,由于空间不连续,寻址困难,增删元素只需修改指针,所以查询慢、增删快。有没有一种数据结构来综合一下数组和链表,以便发挥他们各自的优势?答案是肯定的!就是:哈希表。哈希表具有较快(常量级)的查询速度,及相对较快的增删速度,所以很适合在海量数据的环境中使用。一般实现哈希表的方法采用“拉链法”,我们可以理解为“链表的数组”,如下图:
从上图中,我们可以发现哈希表是由数组+链表组成的,一个长度为16的数组中,每个元素存储的是一个链表的头结点。那么这些元素是按照什么样的规则存储到数组中呢。一般情况是通过hash(key)%len获得,也就是元素的key的哈希值对数组长度取模得到。比如上述哈希表中,12%16=12,28%16=12,108%16=12,140%16=12。所以12、28、108以及140都存储在数组下标为12的位置。它的内部其实是用一个Entity数组来实现的,属性有key、value、next。接下来我会从初始化阶段详细的讲解HashMap的内部结构。
二、HashTable的内部存储结构
HashTable和HashMap采用相同的存储机制,二者的实现基本一致,不同的是:
1、HashMap是非线程安全的,HashTable是线程安全的,内部的方法基本都是synchronized。
2、HashTable不允许有null值的存在。
在HashTable中调用put方法时,如果key为null,直接抛出NullPointerException。其它细微的差别还有,比如初始化Entry数组的大小等等,但基本思想和HashMap一样。
三、HashTable和ConcurrentHashMap的比较
ConcurrentHashMap是线程安全的HashMap的实现。同样是线程安全的类,它与HashTable在同步方面有什么不同呢?
之前我们说,synchronized关键字加锁的原理,其实是对对象加锁,不论你是在方法前加synchronized还是语句块前加,锁住的都是对象整体,但是ConcurrentHashMap的同步机制和这个不同,它不是加synchronized关键字,而是基于lock操作的,这样的目的是保证同步的时候,锁住的不是整个对象。事实上,ConcurrentHashMap可以满足concurrentLevel个线程并发无阻塞的操作集合对象。

ZooKeeper和Diamond有什么不同

本文主要是讨论下两个类似产品:ZooKeeper和Diamond在配置管理这个应用场景上的异同点。
Diamond,顾名思义,寄寓了开发人员对产品稳定性的厚望,希望它像钻石一样,提供稳定的配置访问。Diamond是淘宝网Java中间件团队的核心产品之一,服务于集团线上很多核心应用。目前已经开源,开源地址在:http://code.taobao.org/p/diamond/wiki/index/。

数据持久性

Diamond主要针对的是持久数据,这些数据有个共同的特点是:集群中一批机器都会使用,但是数据的更新频率不大,且希望diamond能够永久存储。
ZooKeeper即可以存储持久数据,也可以存储非持久数据。持久数据和diamond中的持久数据都类似,所谓的非持久数据是指这些数据的生命周期和数据创建者的会话生命周期绑定,一旦会话结束,那么这些非持久数据也会被清除。

推拉模型

本质上,两个产品都是“拉”模式的,即都是通过客户端自己去服务器获取最新数据。具体实现上,两个产品分别如下:
在Diamond中,客户端每隔15s轮询服务器,比对数据是否更新,从而获取最新数据。
在ZooKeeper中,则是通过客户端对相应的数据path注册Watcher,当数据有更新的时候,服务器会有事件通知,注意,这个通知仅仅是告诉客户端对应的数据有更新了,具体数据内容需要客户端根据自己的情况来决定是否需要获取最新数据。
因此在实时性方面,ZooKeeper比Diamond高一些。

服务器数据存储

在数据存储上,ZooKeeper和Diamond差别比较大。
首先来看下Diamond的数据存储。Diamond的数据存储以mysql数据库为中心,所有在mysql中的数据都是最新的,客户端的所有写请求,都会首先写入数据库,同时会dump数据到Server的本地文件中,所有读请求都是直接走这个静态文件。
在ZooKeeper中,所有运行时数据都是存储在内存中,客户端的所有读写操作都是针对这份内存数据来进行的。同时,内存中的数据,ZK会以快照的形式dump到指定文件中去,配合事务日志,帮助服务器在下次重启的时候,能够加载正确的数据到内存中去。

数据模型

Diamond的数据都是以行组织的,这也更便于它使用mysql来管理数据。Diamond的基本数据结构包含dataid,group和content,根据group,可以将一组相关的数据组合起来。
ZooKeeper中,使用树形结构来组织数据,每个节点类型于一个文件系统的路径,一个节点下面也可以创建多个子节点来规则一些相关的数据。

容灾

在容灾方面,diamond做得相当的完备:
1. 所有客户端的读请求,都是直接读取服务器端的本地静态文件,因此,即使数据库挂了,都不会影响diamond的读服务。而读服务在所有使用diamond的应用场景中,占到了绝大部分。
2. Diamond客户端还保存了数据的快照,客户端每次从服务器成功获取数据后,都会把这份数据保存到本地文件系统中,称为快照文件。这个快照文件是为了防止在服务器无法获取数据的时候,能够在这个快照中获取数据。
3. 客户端还会有一个容灾目录,变个容灾目录是在服务器完全不可用的时候,运维人员可以手动在这个容灾目录中创建相关目录结构的数据,diamond就就会优先从这个目录中获取数据。
4. 说到这里,我们就可以给diamond的数据获取优先级作一个总结:
首先都会从容灾目录中获取数据——无法从容灾目录获取数据的话,就通过网络到服务器请求数据——如果无法从服务器获取数据,那么就从本地的snapshot中获取数据。
接下来看看ZooKeepe的容灾,做得很少,只有以下一点:
1. ZooKeeper实现了paxos算法,有效的解决了分布式单点问题。以一个3台机器构成的集群为例,任意一台ZK挂掉,都不会影响集群的数据一致性。
总结:在容灾方面,diamond有很大的优势,也符合了diamond的稳定性要求。

数据大小

Diamond对单个数据的大小,没有严格的限制,通常2M左右的数据大小都是没有问题的。而在ZooKeeper中,由于全量数据都是存储在内存中,并且需求进行集群机器间的数据两步,所以对单个数据的大小有严格的限制,默认单个数据节点的最大数据大小是1M。

数据追加与聚合

Diamond支持对数据的追加与聚合功能,即对同一个dataid的写入操作,可以设置为追加。而ZooKeeper目前不支持,只有覆盖写。