最好免费高清影视seo全称是什么
目录
1、什么是线程安全性？
2、操作的原子性：避免竞态条件
3、锁机制：内置锁和可重入
4、如何用锁来保护状态？
5、同步机制中的活跃性与性能问题
编写线程安全的代码，其核心在于对状态访问操作进行管理，特别是对共享的(Shared)和可变的(Mutable)状态的访问。//核心：对共享并且可变状态进行管理
对象的状态是指存储在状态变量中的数据。状态变量可以是类的实例或成员变量。
一个对象是否需要是线程安全的，取决于它是否被多个线程访问。要使得对象是线程安全的，需要采用同步机制来协同对对象可变状态的访问。如果无法实现协同，那么可能会导致数据破坏以及其他不该出现的结果。//通过同步实现对象的线程安全
Java 中的主要同步机制是关键字 synchronized，它提供了一种独占的加锁方式，此外，还包括 volatile 类型的变量，显式锁 (Explicit Lock)以及原子变量等。//解决同步中的可见性和原子性（顺序）
1、什么是线程安全性？
当多个线程访问某个类时，这个类始终都能表现出正确的行为，那么就称这个类是线程安全的。//所见即所知
public class StatelessFactorizer extends GenericServlet implements Servlet {public void service(ServletRequest req, ServletResponse resp) {//1-从req中获取值BigInteger i = extractFromRequest(req);BigInteger[] factors = factor(i);//2-编码并响应encodeIntoResponse(resp, factors);}
}上述 StatelessFactorizer 是无状态的：它既不包含任何成员变量，也不包含任何对其他类中成员变量的引用。计算过程中的临时状态仅存在于线程栈上的局部变量中，并且只能由正在执行的线程访向。由于线程访问无状态对象的行为并不会影响该对象在其他线程中操作的正确性，因此无状态对象是线程安全的。//不进行共享就不存在线程安全问题
2、操作的原子性：避免竞态条件
假设我们想增加一个“命中计数器”(Hit Counter) 来统计所处理的请求数量。最简单的方法是在 Servlet 中增加一个 long 类型的成员变量，并且每处理一个请求就将这个值加 1，代码如下：
//存在线程安全问题
public class UnsafeCountingFactorizer extends GenericServlet implements Servlet {//计数器private long count = 0;public long getCount() {return count;}public void service(ServletRequest req, ServletResponse resp) {//1-从req中获取值BigInteger i = extractFromRequest(req);BigInteger[] factors = factor(i);++count;//2-编码并响应encodeIntoResponse(resp, factors);}
}我们都知道，虽然递增操作 ++count 看上去只是一个操作，但这个操作并非原子的。实际上，它包含了三个独立的操作：读取 count 的值，将值加 1，然后将计算结果写入 count。这是一个 “读取 - 修改 - 写” 的操作序列，并且其结果状态依赖于之前的状态。//指令是非原子性的，如果步骤乱了，结果也会乱
在上述 UnsafeCountingFactorizer 中存在多个竞态条件，从而使结果变得不可靠。最常见的竞态条件就是 “先检查后执行 (Check-Then-Act)” 操作，即通过一个可能失效的观测结果来决定下一步的动作。//如果前提条件是错误的，那么论证的结果一般也是错误的
比如，首先观察到某个条件为真(例如文件 X 不在)，然后根据这个观察结果执行用应的动作(创建文件X)，但事实上，在你观察到这个结果以及开始创建文件之间，观察结果可能变得无效(另一个线程在这期间创建了文件 X)，从而导致各种问题(未预期的异常数据被覆盖、文件被破等)。//单例问题
为了确保线程安全性，避免竞态条件，“先检查后执行”和“读取 - 修改 - 写入”等操作必须是原子的。
public class CountingFactorizer extends GenericServlet implements Servlet {//使用原子类private final AtomicLong count = new AtomicLong(0);public long getCount() { return count.get(); }public void service(ServletRequest req, ServletResponse resp) {BigInteger i = extractFromRequest(req);BigInteger[] factors = factor(i);count.incrementAndGet();encodeIntoResponse(resp, factors);}
}在实际情况中，应尽可能地使用现有的线程安全对象(例如 AcomicLong)来管理类的状态。与非线程安全的对象相比，判断线程安全对象的状态及其状态转换情况要更加容易，从而也更容易维护和验证线程安全性。//仅对单个变量的安全性有效
3、锁机制：内置锁和可重入
面对多个变量时，原子类并不能保证同步机制有效：
//存在线程安全问题
public class UnsafeCachingFactorizer extends GenericServlet implements Servlet {//原子类变量1private final AtomicReference<BigInteger> lastNumber = new AtomicReference<BigInteger>();//原子类变量2private final AtomicReference<BigInteger[]> lastFactors = new AtomicReference<BigInteger[]>();public void service(ServletRequest req, ServletResponse resp) {BigInteger i = extractFromRequest(req);//两个变量不能保证同时获取或者同时设置if (i.equals(lastNumber.get())) //获取变量1的值encodeIntoResponse(resp, lastFactors.get()); //获取变量2的值else {BigInteger[] factors = factor(i);lastNumber.set(i); //设置变量1的值lastFactors.set(factors); //设置变量2的值encodeIntoResponse(resp, factors);}}
}此时，就需要引入锁机制来确保线程的同步。
Java 提供了一种内置的锁机制来支持原子性：同步代码块(Synchronized Block)。每个Java 对象都可以用做一个实现同步的锁，这些锁被称为内置锁(Intrinsic Lock)或监视器锁(Monitor Lock)。//就是所谓的管程，Synchronized 太常见就不过多介绍了
Synchronized 的问题：使用同步代码块，很容易对代码进行过于极端的保护，虽然解决了安全问题，但带来了性能问题。//锁的粗粒度和细粒度问题
内置锁是可重入的，因此如果某个线程试图获得一个已经由它自己持有的锁，那么这个请求就会成功。“重人”意味着获取锁的操作的粒度是“线”，而不是“调用”。//不可重入会造成自己阻塞自己的问题
重入的一种实现方法是，为每个锁关联一个获取计数值和一个所有者线程。当计数值为 0 时，这个锁就被认为是没有被任何线程持有。当线程请求一个未被持有的锁时，JVM 将记下锁的持有者，并且将获取计数值置为 1。如果同一个线程再次获取这个锁，计数值将递增，而当线程退出同步代码块时计数器会相应地递减。当计数值为 0 时，这个锁将被释放。//重入锁的实现原理
4、如何用锁来保护状态？
锁能使其保护的代码以串行形式来访问，因此可以通过锁来实现对共享状态的独占访问。
下边是一些正确使用锁的建议：
（1）如果用同步来协调对某个变量的访问，那么在访问和操作这个变量的所有位置上都需要使用同步。而且，在访问和操作变量的所有位置上都要使用同一个锁。//对共享变量的读写都要上锁
之所以每个对象都有一个内置锁，只是为了免去显式地创建锁对象。你可以自行构造加锁协议或者同步策略来实现对共享状态的安全访问，并且在程序中自始至终地使用它们。
（2）每个共享的和可变的变量都应该只由一个锁来保护，从而使维护人员知道是哪一个锁。
（3）对于每个包含多个变量的不变性条件，其中涉及的所有变量都需要由同一个锁来保护。
5、同步机制中的活跃性与性能问题
试想，如果同步可以避免竞态条件问题，那么为什么不在每个方法声明时都使用关键字 synchronized 呢?
事实上，如果不加区别地用 synchronized，可能导致程序中出现过多的同步。此外，如果只是将每个方法都作为同步方法，例如 Vector，那么并不足以确保 Vector 上复合操作都是原子的：
//非原子操作
if (!vector.contains(element))vector.add(element);此外，将每个方法都作为同步方法还可能导致活跃性问题(Liveness)或性能问题(Performance)。
如下代码，如果使用 SynchronizedFactorizer 中的同步方式，那么代码的执行性能将非常糟糕。//不能直接把方法一锁了之，虽然实现了线程安全，但付出了太大性能代价
//线程安全
public class SynchronizedFactorizer extends GenericServlet implements Servlet {//成员变量private BigInteger lastNumber;private BigInteger[] lastFactors;//直接锁方法，存在性能问题public synchronized void service(ServletRequest req, ServletResponse resp) {BigInteger i = extractFromRequest(req);if (i.equals(lastNumber))encodeIntoResponse(resp, lastFactors);else {BigInteger[] factors = factor(i);lastNumber = i;lastFactors = factors;encodeIntoResponse(resp, factors);}}
}锁优化思路：缩小同步代码块的作用范围，做到既确保 Servlet 的并发性，同时又维护线程安全性。要确保同步代码块不要过小，并且不要将本应是原子的操作拆分到多个同步代码块中。应该尽量将不影响共享状态且执行时间较长的操作从同步代码块中分离出去，从而在这些操作的执行过程中，其他线程可以访问共享状态。//将粗粒度的锁尽量缩小，将执行时间长的代码进行剥离
重新构造后的 CachedFactorizer 实现了在简单性与并发性 之间的平衡。代码如下：
//线程安全
public class CachedFactorizer extends GenericServlet implements Servlet {//共享变量private BigInteger lastNumber;private BigInteger[] lastFactors;//命中计数器private long hits;//cache命中计数器private long cacheHits;public synchronized long getHits() {return hits;}public synchronized double getCacheHitRatio() {return (double) cacheHits / (double) hits;}public void service(ServletRequest req, ServletResponse resp) {//1-从req获取值BigInteger i = extractFromRequest(req);BigInteger[] factors = null; synchronized (this) { //同步代码块1，对变量进行操作++hits;if (i.equals(lastNumber)) {++cacheHits;factors = lastFactors.clone();}}if (factors == null) {factors = factor(i); //局部变量，不需要进行同步synchronized (this) { //同步代码块2，对变量进行操作lastNumber = i;lastFactors = factors.clone();}}//2-响应：把执行时间长的代码进行剥离encodeIntoResponse(resp, factors);}void encodeIntoResponse(ServletResponse resp, BigInteger[] factors) {}BigInteger extractFromRequest(ServletRequest req) {return new BigInteger("7");}BigInteger[] factor(BigInteger i) {// Doesn't really factorreturn new BigInteger[]{i};}
}在 CachedFactorizer 中不再使用 AtomicLong 类型的命中计数器，而是使用了一个 long 类型的变量。当然也可以使用 AtomicLong 类型，对在单个变量上实现原子操作来说，原子变量非常有用。但此处，由于我们已经使用了同步代码块来构造原子操作，而使用两种不同的同步机制不仅会带来混乱，也不会在性能或安全性上带来任何好处，因此在这里不使用原子变量。//同一个类中，应该只使用一种同步机制，让代码简单易懂。
要判断同步代码块的合理大小，需要在各种设计需求之间进行权衡，包括安全性(必须满足)、简单性和性能。有时候，在简单性与性能之间会发生冲突，但在二者之间通常能找到某种合理的平衡。通常，在简单性与性能之间存在着相互制约因素。当实现某个同步策略时，一定不要盲目地为了性能而牺牲简单性 (这可能会破坏安全性)。//努力做到安全性和性能的平衡
无论是执行计算密集的操作，还是在执行某个可能阻塞的操作，如果持有锁的时间过长，那么都会带来活跃性或性能问题。所以，当执行时间较长的计算或者可能无法快速完成的操作时(例如，网络I/O 或控制台I/O)，一定不要持有锁。//执行时间较长的代码不要持有锁
至此，全文到此结束。