Java线程并发
berber78
这个作者很懒,什么都没留下…
展开
-
线程相关
原子性:操作是不可分割的,就说这个操作是原子操作。比如a++; 这个操作实际是a = a + 1;是可分割的,所以他不是一个原子操作。非原子操作都会存在线程安全问题,需要我们使用同步技术(sychronized)来让它变成一个原子操作。java的concurrent包下提供了一些原子类,比如:AtomicInteger、AtomicLong、AtomicReference等。 可见性:是指线程之原创 2014-12-15 20:38:54 · 708 阅读 · 0 评论 -
线程各种状态
- Sleep 之后还会占用 CPU 资源,而貌似等待就不会; - 要想用wait方法必须先加同步锁。wait不是针对线程Thread/Runnable的,而是针对锁对象的,假设某个Object lock = new Object();线程1(比如消费者线程)调用lock.wait()方法后,线程1就停下,直到其他某个线程(比如生产者线程)调用了lock.notify()或者lock.notif原创 2015-06-02 13:12:17 · 1678 阅读 · 0 评论 -
synchronized杂谈
synchronized 控制对类成员变量的访问:每个类实例可对应一把锁,每个 synchronized 实例方法都必须获得调用该方法的类实例的锁方能执行,否则所属线程阻塞,方法一旦执行,就独占该锁,直到从该方法返回时才将锁释放,此后被阻塞的线程方能获得该锁,重新进入可执行状态。这种机制确保了同一时刻对于每一个类实例,其所有声明为 synchronized 的成员函数中至多只有一个处于可执行状态(因原创 2015-06-12 14:18:09 · 541 阅读 · 0 评论 -
原子性
CPU是按一个一个指令来执行的,每个指令的执行都是不可分割的,原子性的。 为了使一些代码块也具有原子性,可以使用synchronized同步。 JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。个人理解,只要 CPU 被分配给某个线程执行构造方法,则构造期间 CPU 不会切换到其他线程,而是把构造方法这条指令执行完。再进一步说,个人理解,CPU 总是将一条指令执行完才可能切换到其原创 2015-07-16 09:49:30 · 521 阅读 · 0 评论 -
单例模式、双检测锁定DCL、volatile(转)
单例模式最要关心的则是对象创建的次数以及何时被创建。Singleton模式可以是很简单的,它的全部只需要一个类就可以完成(看看这章可怜的UML图)。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来,Singleton模式可以相当的复杂,比头五种模式加起来还复杂,譬如涉及到DCL双锁检测(double checked locking)的讨论、涉及到多个类加载器(ClassLoader)协同时原创 2015-07-15 17:40:11 · 702 阅读 · 0 评论 -
Volatile
int a = 10;int c = a;理论上来讲每次使用a的时候都应该从a的地址来读取变量值,但是这存在一个效率问题,就是每次使用a都要去内存中取变量值,然后再通过系统总线传到CPU处理,这样开销会很大。所以那些编译器优化者故作聪明,把a读进CPU的cache里,像上面的代码,假如a在赋 值期间没有被改变,就直接从CPU的cache里取a的副本来进行赋值。但是bug也显而易见,可能a已经被另一原创 2015-07-16 09:42:54 · 449 阅读 · 0 评论 -
疫苗:HashMap的死循环
在淘宝内网里看到同事发了贴说了一个CPU被100%的线上故障,并且这个事发生了很多次,原因是在Java语言在并发情况下使用HashMap造成Race Condition,从而导致死循环。这个事情我4、5年前也经历过,本来觉得没什么好写的,因为Java的HashMap是非线程安全的,所以在并发下必然出现问题。但是,我发现近几年,很多人都经历过这个事(在网上查“HashMap Infinite Loo转载 2015-10-03 15:34:58 · 1107 阅读 · 0 评论 -
ReentrantLock
ReentrantLock是可重入锁,或者说其持有一个锁计数器,当已持有所的线程再次获得该锁时计数器值加1,每调用一次lock.unlock()时所计数器值减一,直到所计数器值为0,此时线程释放锁; 一般try前执行lock(),try中为受保护代码段; finally中执行unlock()可以保证发生异常 锁可以得到释放 避免死锁的发生; ReentrantLock的主要缺点是方法需要置于...原创 2018-03-13 10:27:39 · 387 阅读 · 0 评论