Java多线程之线程同步
volatile
先看个例子
class Test {
// 定义一个全局变量
private boolean isRun = true;
// 从主线程调用发起
public void process() {
test();
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
stop();
}
// 启动一个子线程循环读取isRun
private void test() {
new Thread(new Runnable() {
@Override
public void run() {
while (isRun) {
// 疑问,如果我这里有一些打印的语句或者线程睡眠的语句,子线程在
// 主线程将isRun改为false的时候,就会跳出死循环,反之,如果循环体
// 内是空的,就算在主线程改了isRun的值,也无法及时跳出循环,why?
// 当然,如果将isRun变量使用volatile修饰就没有此问题
}
}
}).start();
}
private void stop() {
isRun = false;
}
}
有一点是一定的,就是子线程访问isRun的时候会拷贝一份放到自己的线程(工作内存)里,这样在读写的时候可能就不会和外面isRun的值实时是匹配上的。所以就会出现意想不到的问题。
所以我们使用volatile修饰,这样当有多线程同时访问一个变量时,都会自动同步一下。显然这样会带来一定的性能损失,但是如果确实需要还是要这么做的。
但是,有一个问题来了,使用volatile一定能就可解决多线程同步的问题了吗?那我们看下面这个例子:
class TestSynchronize {
// 使用volatile修饰的变量
private volatile int x = 0;
private void add() {
x++;
}
public void test() {
// 启动第一个线程,进行100万次自加
new Thread(new Runnable() {
@Override
public void run() {
for (int i=0; i< 1_000_000; i++) {
add();
}
System.out.println("第一个线程x=" + x);
}
}).start();
// 启动第二个线程,进行100万次自加
new Thread(new Runnable() {
@Override
public void run() {
for (int i=0; i< 1_000_000; i++) {
add();
}
System.out.println("第二个线程x=" + x);
}
}).start();
}
}
我们希望的结果是,最后一个执行完的线程应该是在2_000_000,但是只要你实际测下就发现并不是这样,因为volatile只能保证可见性,但是只要涉及多线程我们一定还听说过原子性这个概念。什么是可见性:
可见性:对于多个线程都在访问的变量,当有个线程在修改的时候,它会保证会将修改的值更新到内存中,而不是只在工作线程中修改,这样当别的线程访问的时候也会去内存中取最新的值,这样就能保证访问到的值是最新的。
那什么又是原子性呢:
原子性:就是一个操作或者多个操作要么都执行,要么都不执行,不会存在执行一半会被打断。
在Java中,对基本数据类型变量的读取和赋值操作是原子性的。但是上述代码中的x++;
显然不是原子操作,可以拆解为:
int temp = x + 1;
x = temp;
那么这就为多线程操作带来不确定性,
1、开始x初始值为0,
2、当线程A调用add()函数时,执行到temp=x+1;
这一行时被中断了,
3、此时切换到线程B的add()函数,线程B完整执行完两行代码后,x = 1了,
4、这个时候线程B又完整的执行了一遍add方法,那么x=2了,
5、此时发生了线程切换,切换到A执行,A接着上次的执行的语句,temp = 1了,接下来执行x = temp;
语句将1赋值给了x。
可是本来x都被B线程加到2了,这下又回去了,经历A和B线程一共三次add()操作,结果x的值只是1。
这就解释了上面那段代码中,两个线程分别加了100万次后,结果最后一个执行完的线程打印的却并不是200万。原因就是add()里面的操作并不是原子性的,而volatile只能保证可见性,不能保证原子性
当然,仅针对上面的按理我们可以将int x = 0;
换一种类型声明,比如使用AtomicInteger x = new AtomicInteger(0);
然后将x++
改成x.incrementAndGet();
这样也能保证原子性,确保多线程操作后数据是符合期望的。
除了针对基本数据类型的,还有对引用操作原子化的,AtomicReference<V>
synchronized
当synchronized修饰一个方法时,那么同一时间只有一个线程可以访问此方法,如果有多个方法都被synchronized修饰的话,当一个线程访问了其中一个方法,别的线程就无法访问其他被synchronized修饰的方法。
相当于有一个监视器,当一个线程访问某个方法,其他线程想访问别的方法时,需要和同一个监视器做确认,这么做看起来不太合理,其实也是合理的,比如有两方法都可能对同一个变量做操作,两个线程能同时访问两个方法,这样数据还是会发生错乱。
当然,我们就有两个方法支持同步访问的场景的,只要我们自己确认两个方法不会存在数据上的错乱,我们可以为每个方法指定自己的监视器,在默认情况下是当前类的对象(this)。
我们分别为setName();
和其他两个方法指定了不同的monitor(监视器),这样当线程A访问上面两个方法的时候,线程B想访问方法setName也是不受影响的:
接下来我们看我们经常写的另一个例子,单例模式:
class TestInstance {
private TestInstance(){}
private static TestInstance sInstance;
public static TestInstance newInstance() {
**// ② 这里判空的目的?**
if (sInstance == null) {
**// ① 为什么锁加在这里?**
synchronized (TestInstance.class) {
**// ③ 这里判空的目的?**
if (sInstance == null) {
sInstance = new TestInstance();
}
}
}
return sInstance;
}
}
我们来依次搞清楚上面的三个问题,
①锁为什么加在里面而不是在方法上加锁,因为加锁后会带来性能上的损失的,单例对象只会创建一次,没必要在实例已经有的时候获取单例时还加锁,对性能是浪费。
②第一个判空的目的就是在已经创建过实例之后的获取操作,不用再经过synchronized判断,这样更快。
③最后一个判空就是防止多个线程都会调到创建实例的操作。
到此这篇关于Java多线程之线程同步的文章就介绍到这了,更多相关Java线程同步内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网!
免责声明:
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341