1, 保证线程安全的三种方法
:
a, 不要跨线程访问共享变量
b, 使共享变量是
final类型的
c, 将共享变量的操作加上同步
2, 一开始就将类设计成线程安全的
, 比在后期重新修复它
,更容易
.
3, 编写多线程程序
, 首先
保证它是正确的
, 其次再考虑性能
.
4, 无状态或只读对象永远是线程安全的
.
5, 不要将一个共享变量裸露在多线程环境下
(无
同步或不可变性保护
)
6, 多线程环境下的延迟加载需要同步的保护
,
因为延迟加载会造成对象重复实例化
7,
对于
volatile
声明的数值类型变量进行
运算
,
往往是不安全的
(volatile
只能保证可见性
,
不能保证原子性
).
详见
volatile
原理与技巧中
,
脏数据问题讨论
.
8,
当一个线程请求获得它自己占有的锁时
(
同一把锁的嵌套使用
),
我们称该锁为可重入锁
.
在
jdk1.5
并发包中
,
提供了可重入锁的
java
实现
-ReentrantLock.
9,
每个共享变量
,
都应该由一个唯一确定的锁保护
.
创建与变量相同数目的
ReentrantLock,
使他们负责每个变量的线程安全
.
10,虽然缩小同步块的范围
, 可以提升系统性能
.
但在保证原子性的情况下
, 不
可将原子操作分解成多个
synchronized块
.
11, 在没有同步的情况下
, 编
译器与处理器运行时的指令执行顺序可能完全出乎意料
.
原因是
, 编译器或处理器为了
优化自身执行效率
, 而对指令进行了的重排
序
(reordering).
12, 当一个线程在没有同步的情况下读取变量
, 它可能会得到一个过期值
,
但是至少它可以看到那个
线程在当时设定的一个真实数值
. 而不是凭空而来的值
. 这种安全保证
, 称之为最低限的安全性
(out-of-thin-air safety)
在开发并发应用程序时
, 有时
为了大幅度提高系统的吞吐量与性能
, 会采
用这种无保障的做法
.
但是针对
, 数值的运算
, 仍旧是被否决的
.
13, volatile
变量
,
只能保证可见性
,
无法保证原子性
.
详见
volatile原理与技巧
14, 某些耗时较长的网络操作或
IO, 确保执行时
, 不
要占有锁
.
15,
发布
(publish)
对象
,
指的是使它能够被当前范围之外的代码所使用
.(
引用传递
)
对象逸出
(escape),
指的是一个对象在尚未准备好时将它发布
.
原则
:
为防止逸出
,
对象必须要被完全构造完后
,
才可以被发布
(
最好
