java8支持的锁类型的简单介绍
今天给各位分享java8支持的锁类型的知识,其中也会对进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
在java中有哪些锁
给你整理了Java中的一些锁:
公平锁/非公平锁
可重入锁
独享锁/共享锁
互斥锁/读写锁
乐观锁/悲观锁
分段锁
偏向锁/轻量级锁/重量级锁
自旋锁
上面是很多锁的名词,这些分类并不是全是指锁的状态,有的指锁的特性,有的指锁的设计
Java8这10个特性你知道多少
下面给你列举Java8的10个特性:
1、default方法
这是Java语言的一个新特性,现在接口类里可以包含方法体(这就是default方法)了。这些方法会隐式的添加到实现这个接口的每个子类中。
2、终止进程
一旦启动外部进程的话,当这个进程崩溃,挂起,或者CPU到达100%的时候,你就得回来擦屁股了。Process类现在增加了两个新的方法,可以来教训下那些不听话的进程了。第一个是isAlive()方法,有了它你可以判断进程是否还活着。第二个方法则更加强大,它叫destroyForcibly(),你可以用它来强制的杀掉一个已经超时或者不再需要的进程。
3、StampedLock
Java 8引入了一个新的读写锁,叫做StampedLock。它不仅更快,同时还提供了一系列强大的API来实现乐观锁,这样如果没有写操作在访问临界区域的话,你只需很低的开销就能获取到一个读锁。访问结束后你可以查询锁来判断这期间是否发生了写操作,如果有的话再选择进行重试,升级锁,或者放弃这个操作。
4、并发计数器
这是多线程程序会用到的另一个小工具。它提供了简单高效的新接口来实现多线程的并发读写计数器的功能,和AtomicInteger比起来,它要更快一些。相当赞的工具。
5、Optional
Java 8借鉴了Scala和Haskell,提供了一个新的Optional模板,可以用它来封装可能为空的引用。这绝不是终结空指针的银弹,更多只是使API的设计者可以在代码层面声明一个方法可能会返回空值,调用方应该注意这种情况。正因为这个,这只对新的API有效,前提是调用方不要让引用逃逸出封装类,否则的话引用可能会在外面被不安全的废弃掉。
6、万物皆可注解
还有一个小的改进就是现在Java注解可以支持任意类型了。之前只有像类和方法声明之类的才能使用注解。在Java 8里面,当类型转化甚至分配新对象的时候,都可以在声明变量或者参数的时候使用注解。这是Java为了更好地支持静态分析及检测工具(比如FireBug)而做的工作中的一部分。这是个很不错的特性,但是和Java 7的invokeDynamic一样,它的真正价值取决于社区以后如何去使用它。
7、数值溢出
这些方法早就该出现在Java的核心类库里了。我有个癖好就是去测试整型超出2^32时溢出的情况,搞出一些恶心的随机BUG来(怎么会得到这么奇怪的一个值?)。
同样的,这也不是什么银弹,只不过是提供了一组函数,这样你在使用+/*操作符进行数值操作的时候,如果出现了溢出,会抛一个异常。如果我可以决定的话,我会把它作为JVM的默认模式,显式的标明函数会出现数值溢出。
8、目录遍历
遍历目录树这种事通常都得上Google搜下怎么实现(你很可能用的是Apache.FileUtils)。Java 8给Files类做了一次整容手术,增加了十个新的方法。我最喜欢的一个是walk()方法,它遍历目录后会创建出一个惰性的流(文件系统很大的情况下非常有用)。
9、增强的随机数生成
现在经常都在讨论密码或者密钥容易遭受攻击的事。程序的安全性是项很复杂的工程,并且很容易出错。这就是我为什么喜欢这个新的SecureRandom.getinstanceStrong()方法的原因,它能自动选择出当前JVM可用的最佳的随机数生成器。这样减少了获取失败的机率,同时也避免了默认的弱随机数生成器可能会导致密钥或者加密值容易被黑客攻破的问题。
10、Date.toInstant()
Java 8引入了一个新的日期API。这不难理解,因为现有的这个实在是太难用了。实际上Joda一直以来都是Java日期API的首选。不过尽管有了新的API,但仍有一个严重的问题——大量的旧代码和库仍然在使用老的API。并且我们还知道这种现状仍将继续存在下去。到底该怎么做呢?
Java 8很优雅的解决了这个问题,它给Date类增加了一个新的方法toInstant(),它可以将Date转化成新的实现。这样你马上就可以切换到新的API,尽管现有的代码还在使用老的日期API(并且在可预见的未来仍将继续这样)。
java 锁有几种
乐观锁/悲观锁
乐观锁与悲观锁不是指具体的什么类型的锁,而是指看待并发同步的角度。
悲观锁认为对于同一个数据的并发操作,一定是会发生修改的,哪怕没有修改,也会认为修改。因此对于同一个数据的并发操作,悲观锁采取加锁的形式。悲观的认为,不加锁的并发操作一定会出问题。
乐观锁则认为对于同一个数据的并发操作,是不会发生修改的。在更新数据的时候,会采用尝试更新,不断重新的方式更新数据。乐观的认为,不加锁的并发操作是没有事情的。
从上面的描述我们可以看出,悲观锁适合写操作非常多的场景,乐观锁适合读操作非常多的场景,不加锁会带来大量的性能提升。
公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取锁。
优点:在于吞吐量比公平锁大。
缺点:可能会造成优先级反转或者某些线程饥饿现象(一直拿不到锁)。
对于Java ReentrantLock而言,通过构造函数指定该锁是否是公平锁,默认是非公平锁。
对于Synchronized而言,也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度,所以并没有任何办法使其变成公平锁。
可重入锁
可重入锁的概念是自己可以再次获取自己的内部锁。
举个例子,比如一条线程获得了某个对象的锁,此时这个对象锁还没有释放,当其再次想要获取这个对象的锁的时候还是可以获取的(如果不可重入的锁的话,此刻会造成死锁)。说的更高深一点可重入锁是一种递归无阻塞的同步机制。
对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁,其名字是Re entrant Lock重新进入锁。
对于Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。
独享锁/共享锁
独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。
对于Java ReentrantLock(互斥锁)而言,其是独享锁。
但是对于Lock的另一个实现类ReadWriteLock(读写锁),其读锁是共享锁,其写锁是独享锁。读锁的共享锁可保证并发读是非常高效的,读写,写读 ,写写的过程是互斥的。
对于Synchronized而言,当然是独享锁。
分段锁
分段锁其实是一种锁的设计,并不是具体的一种锁。对于ConcurrentHashMap而言,其并发的实现就是通过分段锁的形式来实现高效的并发操作。
我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想,ConcurrentHashMap中的分段锁称为Segment,它即类似于HashMap(JDK7与JDK8中HashMap的实现)的结构,即内部拥有一个Entry数组,数组中的每个元素又是一个链表;同时又是一个ReentrantLock(Segment继承了ReentrantLock)。
当需要put元素的时候,并不是对整个hashmap进行加锁,而是先通过hashcode来知道他要放在那一个分段中,然后对这个分段进行加锁,所以当多线程put的时候,只要不是放在一个分段中,就实现了真正的并行的插入。
但是,在统计size的时候,可就是获取hashmap全局信息的时候,就需要获取所有的分段锁才能统计。
分段锁的设计目的是细化锁的粒度,当操作不需要更新整个数组的时候,就仅仅针对数组中的一项进行加锁操作。
互斥锁:
无法获取琐时,进线程立刻放弃剩余的时间片并进入阻塞(或者说挂起)状态,同时保存寄存器和程序计数器的内容(保存现场,上下文切换的前半部分),当可以获取锁时,进线程激活,等待被调度进CPU并恢复现场(上下文切换下半部分)
上下文切换会带来数十微秒的开销,不要在性能敏感的地方用互斥锁
读写锁:
1)多个读者可以同时进行读
2)写者必须互斥(只允许一个写者写,也不能读者写者同时进行)
3)写者优先于读者(一旦有写者,则后续读者必须等待,唤醒时优先考虑写者)
自旋锁:
自旋锁是指尝试获取锁的线程不会立即阻塞,而是采用循环的方式去尝试获取锁,这样的好处是减少线程上下文切换的消耗,缺点是循环会消耗CPU。
关于java8支持的锁类型和的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
发布于:2022-12-24,除非注明,否则均为
原创文章,转载请注明出处。