]]>
]]>
?/span>入锁Q?span class="hilite1" style="background-color: #ffff00; ">ReentrantLockQ是一U递归无阻塞的同步机制。以前一直认为它是synchronized的简单替代，而且实现机制也不相差太远。不q最q实践过E中发现它们之间q是有着天壤之别?/p>
以下?a target="_blank" style="color: #006699; text-decoration: underline; ">官方说明Q一个可重入的互斥锁?LockQ它h与?synchronized Ҏ(gu)和语句所讉K的隐式监视器锁定相同的一些基本行为和语义Q但功能更强大?span class="hilite1" style="background-color: #ffff00; ">ReentrantLock 由最q成功获得锁定，q且q没有释放该锁定的线E所拥有。当锁定没有被另一个线E所拥有Ӟ调用 lock 的线E将成功获取该锁定ƈq回。如果当前线E已l拥有该锁定Q此Ҏ(gu)立卌回。可以?isHeldByCurrentThread() ?getHoldCount() Ҏ(gu)来检查此情况是否发生?/p>
它提供了(jin)lock()Ҏ(gu)Q?br /> 如果该锁定没有被另一个线E保持，则获取该锁定q立卌回，锁定的保持计数讄?1?br /> 如果当前U程已经保持该锁定，则将保持计数?1Qƈ且该Ҏ(gu)立即q回?br /> 如果该锁定被另一个线E保持，则出于线E调度的目的Q禁用当前线E，q且在获得锁定之前，该线E将一直处于休眠状态，此时锁定保持计数被设|ؓ(f) 1?/p>
最q在研究Java concurrent中关于Q务调度的实现ӞM(jin)延迟队列DelayQueue的一些代码，比如take()。该Ҏ(gu)的主要功能是从优先队列（PriorityQueueQ取Z个最应该执行的Q务（最优|(j)Q如果该d的预订执行时间未刎ͼ则需要waitq段旉差。反之，如果旉C(jin)Q则q回该Q务。而offer()Ҏ(gu)是将一个Q务添加到该队列中?/p>
后来产生?jin)一个疑问：(x)如果最应该执行的Q务是一个小时后执行的，而此旉要提交一?0U后执行的Q务，?x)出C么状况？q是先看看take()的源代码Q?/p>
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
try {
for (;;) {
E first = q.peek();
if (first == null) {
available.await();
} else {
long delay = first.getDelay(TimeUnit.NANOSECONDS);
if (delay > 0) {
long tl = available.awaitNanos(delay);
} else {
E x = q.poll();
assert x != null;
if (q.size() != 0)
available.signalAll(); // wake up other takers
return x;
}
}
}
} finally {
lock.unlock();
}
}
而以下是offer()的源代码:
final ReentrantLock lock = this.lock;
lock.lock();
try {
E first = q.peek();
q.offer(e);
if (first == null || e.compareTo(first) < 0)
available.signalAll();
return true;
} finally {
lock.unlock();
}
}
如代码所C，take()和offer()都是lock?jin)重入锁。如果按照synchronized的思维Q用诸如synchronized(obj)的方法）(j)Q这两个Ҏ(gu)是互斥的。回到刚才的疑问Qtake()Ҏ(gu)需要等?个小时才能返回，而offer()需要马上提交一?0U后q行的Q务，?x)不会(x)一直等待take()q回后才能提交呢Q答案是否定的，通过~写验证代码也说明了(jin)q一炏V这让我寚w入锁有了(jin)更大的兴，它确实是一个无d的锁?/p>
下面的代码也许能说明问题Q运行了(jin)4个线E，每一ơ运行前打印l(f)ock的当前状态。运行后都要{待5U钟?/p>
final ExecutorService exec = Executors.newFixedThreadPool(4);
final ReentrantLock lock = new ReentrantLock();
final Condition con = lock.newCondition();
final int time = 5;
final Runnable add = new Runnable() {
public void run() {
System.out.println("Pre " + lock);
lock.lock();
try {
con.await(time, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
System.out.println("Post " + lock.toString());
lock.unlock();
}
}
};
for(int index = 0; index < 4; index++)
exec.submit(add);
exec.shutdown();
}
q是它的输出Q?br />
Pre ReentrantLock@a59698[Unlocked] 每一个线E的锁状态都?#8220;Unlocked”,所以都可以q行。但在把con.awaitҎ(gu)Thread.sleep(5000)Ӟ输出变成了(jin)Q?br />
Pre ReentrantLock@a59698[Unlocked] 以上的对比说明线E在{待?con.await)Q已l不在拥有（keepQ该锁了(jin)Q所以其他线E就可以获得重入锁了(jin)?br />
有必要会(x)q头再看看Java官方的解释：(x)“如果该锁定被另一个线E保持，则出于线E调度的目的Q禁用当前线E，q且在获得锁定之前，该线E将一直处于休眠状?#8221;。我对这里的“保持”的理解是指非wait状态外的所有状态，比如U程Sleep、for循环{一切有CPU参与的活动。一旦线E进入wait状态后Q它?yu)׃再keepq个锁了(jin)Q其他线E就可以获得该锁Q当该线E被唤醒Q触发信h者timeoutQ后Q就接着执行Q会(x)重新“保持”锁，当然前提依然是其他线E已l不?#8220;保持”?jin)该重入锁?/p>
ȝ一句话Q对于重入锁而言Q?lock"?keep"是两个不同的概念。lock?jin)锁Q不一定keep锁，但keep?jin)锁一定已llock?jin)锁?/p>
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Unlocked]
Pre ReentrantLock@a59698[Unlocked]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-2]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-3]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-4]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Pre ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-1]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-2]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-3]
Post ReentrantLock@a59698[Locked by thread pool-1-thread-4]
]]>
For information about ongoing work on the memory model, see Bill Pugh's Java Memory Model pages.
Consider the tiny class, defined without any synchronization:
final class SetCheck {
private int a = 0;
private long b = 0;
void set() {
a = 1;
b = -1;
}
boolean check() {
return ((b == 0) ||
(b == -1 && a == 1));
}
}
In a purely sequential language, the method check could never return false. This holds even though compilers, run-time systems, and hardware might process this code in a way that you might not intuitively expect. For example, any of the following might apply to the execution of method set:
- The compiler may rearrange the order of the statements, so b may be assigned before a. If the method is inlined, the compiler may further rearrange the orders with respect to yet other statements.
- The processor may rearrange the execution order of machine instructions corresponding to the statements, or even execute them at the same time.
- The memory system (as governed by cache control units) may rearrange the order in which writes are committed to memory cells corresponding to the variables. These writes may overlap with other computations and memory actions.
- The compiler, processor, and/or memory system may interleave the machine-level effects of the two statements. For example on a 32-bit machine, the high-order word of b may be written first, followed by the write to a, followed by the write to the low-order word of b.
- The compiler, processor, and/or memory system may cause the memory cells representing the variables not to be updated until sometime after (if ever) a subsequent check is called, but instead to maintain the corresponding values (for example in CPU registers) in such a way that the code still has the intended effect.
Things are different in concurrent programming. Here, it is entirely possible for check to be called in one thread while set is being executed in another, in which case the check might be "spying" on the optimized execution of set. And if any of the above manipulations occur, it is possible for check to return false. For example, as detailed below, check could read a value for the long b that is neither 0 nor -1, but instead a half-written in-between value. Also, out-of-order execution of the statements in set may cause check to read b as -1 but then read a as still 0.
In other words, not only may concurrent executions be interleaved, but they may also be reordered and otherwise manipulated in an optimized form that bears little resemblance to their source code. As compiler and run-time technology matures and multiprocessors become more prevalent, such phenomena become more common. They can lead to surprising results for programmers with backgrounds in sequential programming (in other words, just about all programmers) who have never been exposed to the underlying execution properties of allegedly sequential code. This can be the source of subtle concurrent programming errors.
In almost all cases, there is an obvious, simple way to avoid contemplation of all the complexities arising in concurrent programs due to optimized execution mechanics: Use synchronization. For example, if both methods in class SetCheck are declared as synchronized, then you can be sure that no internal processing details can affect the intended outcome of this code.
But sometimes you cannot or do not want to use synchronization. Or perhaps you must reason about someone else's code that does not use it. In these cases you must rely on the minimal guarantees about resulting semantics spelled out by the Java Memory Model. This model allows the kinds of manipulations listed above, but bounds their potential effects on execution semantics and additionally points to some techniques programmers can use to control some aspects of these semantics (most of which are discussed in K?).
The Java Memory Model is part of The JavaTM Language Specification, described primarily in JLS chapter 17. Here, we discuss only the basic motivation, properties, and programming consequences of the model. The treatment here reflects a few clarifications and updates that are missing from the first edition of JLS.
The assumptions underlying the model can be viewed as an idealization of a standard SMP machine of the sort described in K?.4:
For purposes of the model, every thread can be thought of as running on a different CPU from any other thread. Even on multiprocessors, this is infrequent in practice, but the fact that this CPU-per-thread mapping is among the legal ways to implement threads accounts for some of the model's initially surprising properties. For example, because CPUs hold registers that cannot be directly accessed by other CPUs, the model must allow for cases in which one thread does not know about values being manipulated by another thread. However, the impact of the model is by no means restricted to multiprocessors. The actions of compilers and processors can lead to identical concerns even on single-CPU systems.
The model does not specifically address whether the kinds of execution tactics discussed above are performed by compilers, CPUs, cache controllers, or any other mechanism. It does not even discuss them in terms of classes, objects, and methods familiar to programmers. Instead, the model defines an abstract relation between threads and main memory. Every thread is defined to have a working memory (an abstraction of caches and registers) in which to store values. The model guarantees a few properties surrounding the interactions of instruction sequences corresponding to methods and memory cells corresponding to fields. Most rules are phrased in terms of when values must be transferred between the main memory and per-thread working memory. The rules address three intertwined issues:
- Atomicity
- Which instructions must have indivisible effects. For purposes of the model, these rules need to be stated only for simple reads and writes of memory cells representing fields - instance and static variables, also including array elements, but not including local variables inside methods.
- Visibility
- Under what conditions the effects of one thread are visible to another. The effects of interest here are writes to fields, as seen via reads of those fields.
- Ordering
- Under what conditions the effects of operations can appear out of order to any given thread. The main ordering issues surround reads and writes associated with sequences of assignment statements.
When synchronization is not used or is used inconsistently, answers become more complex. The guarantees made by the memory model are weaker than most programmers intuitively expect, and are also weaker than those typically provided on any given JVM implementation. This imposes additional obligations on programmers attempting to ensure the object consistency relations that lie at the heart of exclusion practices: Objects must maintain invariants as seen by all threads that rely on them, not just by the thread performing any given state modification.
The most important rules and properties specified by the model are discussed below.
Atomicity
Accesses and updates to the memory cells corresponding to fields of any type except long or double are guaranteed to be atomic. This includes fields serving as references to other objects. Additionally, atomicity extends to volatile long and double. (Even though non-volatile longs and doubles are not guaranteed atomic, they are of course allowed to be.)Atomicity guarantees ensure that when a non-long/double field is used in an expression, you will obtain either its initial value or some value that was written by some thread, but not some jumble of bits resulting from two or more threads both trying to write values at the same time. However, as seen below, atomicity alone does not guarantee that you will get the value most recently written by any thread. For this reason, atomicity guarantees per se normally have little impact on concurrent program design.
Visibility
Changes to fields made by one thread are guaranteed to be visible to other threads only under the following conditions:- A writing thread releases a synchronization lock and a reading thread subsequently acquires that same synchronization lock.
In essence, releasing a lock forces a flush of all writes from working memory employed by the thread, and acquiring a lock forces a (re)load of the values of accessible fields. While lock actions provide exclusion only for the operations performed within a synchronized method or block, these memory effects are defined to cover all fields used by the thread performing the action.
Note the double meaning of synchronized: it deals with locks that permit higher-level synchronization protocols, while at the same time dealing with the memory system (sometimes via low-level memory barrier machine instructions) to keep value representations in synch across threads. This reflects one way in which concurrent programming bears more similarity to distributed programming than to sequential programming. The latter sense of synchronized may be viewed as a mechanism by which a method running in one thread indicates that it is willing to send and/or receive changes to variables to and from methods running in other threads. From this point of view, using locks and passing messages might be seen merely as syntactic variants of each other.
- If a field is declared as volatile, any value written to it is flushed and made visible by the writer thread before the writer thread performs any further memory operation (i.e., for the purposes at hand it is flushed immediately). Reader threads must reload the values of volatile fields upon each access.
- The first time a thread accesses a field of an object, it sees either the initial value of the field or a value since written by some other thread.
Among other consequences, it is bad practice to make available the reference to an incompletely constructed object (see K?.2). It can also be risky to start new threads inside a constructor, especially in a class that may be subclassed. Thread.start has the same memory effects as a lock release by the thread calling start, followed by a lock acquire by the started thread. If a Runnable superclass invokes new Thread(this).start() before subclass constructors execute, then the object might not be fully initialized when the run method executes. Similarly, if you create and start a new thread T and then create an object X used by thread T, you cannot be sure that the fields of X will be visible to T unless you employ synchronization surrounding all references to object X. Or, when applicable, you can create X before starting T.
- As a thread terminates, all written variables are flushed to main memory. For example, if one thread synchronizes on the termination of another thread using Thread.join, then it is guaranteed to see the effects made by that thread (see K?.2).
The memory model guarantees that, given the eventual occurrence of the above operations, a particular update to a particular field made by one thread will eventually be visible to another. But eventually can be an arbitrarily long time. Long stretches of code in threads that use no synchronization can be hopelessly out of synch with other threads with respect to values of fields. In particular, it is always wrong to write loops waiting for values written by other threads unless the fields are volatile or accessed via synchronization (see K?.6).
The model also allows inconsistent visibility in the absence of synchronization. For example, it is possible to obtain a fresh value for one field of an object, but a stale value for another. Similarly, it is possible to read a fresh, updated value of a reference variable, but a stale value of one of the fields of the object now being referenced.
However, the rules do not require visibility failures across threads, they merely allow these failures to occur. This is one aspect of the fact that not using synchronization in multithreaded code doesn't guarantee safety violations, it just allows them. On most current JVM implementations and platforms, even those employing multiple processors, detectable visibility failures rarely occur. The use of common caches across threads sharing a CPU, the lack of aggressive compiler-based optimizations, and the presence of strong cache consistency hardware often cause values to act as if they propagate immediately among threads. This makes testing for freedom from visibility-based errors impractical, since such errors might occur extremely rarely, or only on platforms you do not have access to, or only on those that have not even been built yet. These same comments apply to multithreaded safety failures more generally. Concurrent programs that do not use synchronization fail for many reasons, including memory consistency problems.
Ordering
Ordering rules fall under two cases, within-thread and between-thread:- From the point of view of the thread performing the actions in a method, instructions proceed in the normal as-if-serial manner that applies in sequential programming languages.
- From the point of view of other threads that might be "spying" on this thread by concurrently running unsynchronized methods, almost anything can happen. The only useful constraint is that the relative orderings of synchronized methods and blocks, as well as operations on volatile fields, are always preserved.
Note that the within-thread point of view is implicitly adopted in all other discussions of semantics in JLS. For example, arithmetic expression evaluation is performed in left-to-right order (JLS section 15.6) as viewed by the thread performing the operations, but not necessarily as viewed by other threads.
The within-thread as-if-serial property is helpful only when only one thread at a time is manipulating variables, due to synchronization, structural exclusion, or pure chance. When multiple threads are all running unsynchronized code that reads and writes common fields, then arbitrary interleavings, atomicity failures, race conditions, and visibility failures may result in execution patterns that make the notion of as-if-serial just about meaningless with respect to any given thread.
Even though JLS addresses some particular legal and illegal reorderings that can occur, interactions with these other issues reduce practical guarantees to saying that the results may reflect just about any possible interleaving of just about any possible reordering. So there is no point in trying to reason about the ordering properties of such code.
Volatile
In terms of atomicity, visibility, and ordering, declaring a field as volatile is nearly identical in effect to using a little fully synchronized class protecting only that field via get/set methods, as in:final class VFloat {
private float value;
final synchronized void set(float f) { value = f; }
final synchronized float get() { return value; }
}
Declaring a field as volatile differs only in that no locking is involved. In particular, composite read/write operations such as the "++'' operation on volatile variables are not performed atomically.
Also, ordering and visibility effects surround only the single access or update to the volatile field itself. Declaring a reference field as volatile does not ensure visibility of non-volatile fields that are accessed via this reference. Similarly, declaring an array field as volatile does not ensure visibility of its elements. Volatility cannot be manually propagated for arrays because array elements themselves cannot be declared as volatile.
Because no locking is involved, declaring fields as volatile is likely to be cheaper than using synchronization, or at least no more expensive. However, if volatile fields are accessed frequently inside methods, their use is likely to lead to slower performance than would locking the entire methods.
Declaring fields as volatile can be useful when you do not need locking for any other reason, yet values must be accurately accessible across multiple threads. This may occur when:
- The field need not obey any invariants with respect to others.
- Writes to the field do not depend on its current value.
- No thread ever writes an illegal value with respect to intended semantics.
- The actions of readers do not depend on values of other non-volatile fields.
]]>
大多数编E语a的语a规范都不?x)谈到线E和q发的问题；因ؓ(f)一直以来，q些问题都是留给q_或操作系l去详细说明的。但是，Java 语言规范QJLSQ却明确包括一个线E模型，q提供了(jin)一些语a元素供开发h员用以保证他们E序的线E安全?/p>
对线E的明确支持有利也有弊。它使得我们在写E序时更Ҏ(gu)利用U程的功能和便利Q但同时也意味着我们不得不注意所写类的线E安全，因ؓ(f)Mc都很有可能被用在一个多U程的环境内?/p>
许多用户W一ơ发C们不得不ȝ解线E的概念的时候，q不是因Z们在写创建和理U程的程序，而是因ؓ(f)他们正在用一个本w是多线E的工具或框架。Q何用q?Swing GUI 框架或写q小服务E序?JSP 늚开发h员（不管有没有意识到Q都曄被线E的复杂性困扰过?/p>
Java 设计师是惛_ZU语aQ之能够很好地q行在现代的gQ包括多处理器系l上。要辑ֈq一目的Q管理线E间协调的工作主要推l了(jin)软g开发h员；E序员必L定线E间׃n数据的位|。在 Java E序中，用来理U程间协调工作的主要工具?synchronized 关键字。在~少同步的情况下QJVM 可以很自由地对不同线E内执行的操作进行计时和排序。在大部分情况下Q这正是我们惌的，因ؓ(f)q样可以提高性能Q但它也l程序员带来?jin)额外的负担Q他们不得不自己识别什么时候这U性能的提高会(x)危及(qing)E序的正性?/p>
大部?Java E序员对同步的块或方法的理解是完全根据用互斥（互斥信号量）(j)或定义一个(f)界段Q一个必d子性地执行的代码块Q。虽?synchronized 的语义中实包括互斥和原子性，但在程q入之前和在程退Z后发生的事情要复杂得多?/p>
synchronized 的语义确实保证了(jin)一ơ只有一个线E可以访问被保护的区D，但同时还包括同步U程在主存内互相作用的规则。理?Java 内存模型QJMMQ的一个好Ҏ(gu)是把各个线E想像成q行在相互分ȝ处理器上Q所有的处理器存取同一块主存空_(d)每个处理器有自己的缓存，但这些缓存可能ƈ不dd同步。在~少同步的情况下QJMM ?x)允怸个线E在同一个内存地址上看C同的倹{而当用一个管E（锁）(j)q行同步的时候，一旦申请加?jin)锁QJMM ׃(x)马上要求该缓存失效，然后在它被释攑։对它q行hQ把修改q的内存位置写回dQ。不隄Zؓ(f)什么同步会(x)对程序的性能影响q么大；频繁地刷新缓存代价会(x)很大?/p>
  |
|
如果同步不适当Q后果是很严重的Q会(x)造成数据混ؕ和争用情况，DE序崩溃Q生不正确的结果，或者是不可预计的运行。更p的是，q些情况可能很少发生且具有偶然性（使得问题很难被监和重现Q。如果测试环境和开发环境有很大的不同，无论是配|的不同Q还是负L(fng)不同Q都有可能得这些问题在试环境中根本不出现Q从而得出错误的l论Q我们的E序是正的Q而事实上q些问题只是q没出现而已?/p>
|
|
另一斚wQ不当或q度C用同步会(x)D其它问题Q比如性能很差和死锁。当?dng)性能差虽然不如数据乱那么严重，但也是一个严重的问题Q因此同样不可忽视。编写优U的多U程E序需要用好的运行\U，_的同步可以(zhn)的数据不发生乱，但不需要滥用到L担死锁或不必要地削弱E序性能的风险?/p>
|
|
׃包括~存h和设|失效的q程QJava 语言中的同步块通常比许多^台提供的临界D设备代h大，q些临界D通常是用一个原子性的“test and set bit”机器指o(h)实现的。即使一个程序只包括一个在单一处理器上q行的单U程Q一个同步的Ҏ(gu)调用仍要比非同步的方法调用慢。如果同步时q发生锁定争用，那么性能上付出的代h(hun)?x)大得多Q因Z(x)需要几个线E切换和pȝ调用?/p>
q运的是Q随着每一版的 JVM 的不断改q，既提高了(jin) Java E序的M性能Q同时也相对减少?jin)同步的代h(hun)Qƈ且将来还可能?x)有q一步的改进。此外，同步的性能代h(hun)l常是被夸大的。一个著名的资料来源曾l引证说一个同步的Ҏ(gu)调用比一个非同步的方法调用慢 50 倍。虽然这句话有可能是真的Q但也会(x)产生误导Q而且已经D?jin)许多开发h员即使在需要的时候也避免使用同步?/p>
严格依照癑ֈ比计同步的性能损失q没有多大意义，因ؓ(f)一个无争用的同步给一个块或方法带来的是固定的性能损失。而这一固定的gq带来的性能损失癑ֈ比取决于在该同步块内做了(jin)多少工作。对一?em>I?/em>Ҏ(gu)的同步调用可能要比对一个空Ҏ(gu)的非同步调用?20 倍，但我们多长时间才调用一ơ空Ҏ(gu)呢？当我们用更有代表性的方法来衡量同步损失Ӟ癑ֈ数很快就下降到可以容忍的范围之内?/p>
?1 把一些这U数据放在一h看。它列D?jin)一些不同的实例Q不同的q_和不同的 JVM 下一个同步的Ҏ(gu)调用相对于一个非同步的方法调用的损失。在每一个实例下Q我q行一个简单的E序Q测定@环调用一个方?10Q?00Q?00 ơ所需的运行时_(d)我调用了(jin)同步和非同步两个版本Qƈ比较?jin)结果。表g的数据是同步版本的运行时间相对于非同步版本的q行旉的比率；它显CZ(jin)同步的性能损失。每ơ运行调用的都是清单 1 中的单方法之一?/p>
表格 1 中显CZ(jin)同步Ҏ(gu)调用相对于非同步Ҏ(gu)调用的相Ҏ(gu)能Qؓ(f)?jin)用l对的标准测定性能损失Q必考虑?JVM 速度提高的因素，qƈ没有在数据中体现出来。在大多数测试中Q每?JVM 的更高版本都?x)?JVM 的M性能得到很大提高Q很有可?1.4 版的 Java 虚拟机发行的时候，它的性能q会(x)有进一步的提高?/p>
| JDK | staticEmpty | empty | fetch | hashmapGet | singleton | create |
| Linux / JDK 1.1 | 9.2 | 2.4 | 2.5 | n/a | 2.0 | 1.42 |
| Linux / IBM Java SDK 1.1 | 33.9 | 18.4 | 14.1 | n/a | 6.9 | 1.2 |
| Linux / JDK 1.2 | 2.5 | 2.2 | 2.2 | 1.64 | 2.2 | 1.4 |
| Linux / JDK 1.3 (no JIT) | 2.52 | 2.58 | 2.02 | 1.44 | 1.4 | 1.1 |
| Linux / JDK 1.3 -server | 28.9 | 21.0 | 39.0 | 1.87 | 9.0 | 2.3 |
| Linux / JDK 1.3 -client | 21.2 | 4.2 | 4.3 | 1.7 | 5.2 | 2.1 |
| Linux / IBM Java SDK 1.3 | 8.2 | 33.4 | 33.4 | 1.7 | 20.7 | 35.3 |
| Linux / gcj 3.0 | 2.1 | 3.6 | 3.3 | 1.2 | 2.4 | 2.1 |
| Solaris / JDK 1.1 | 38.6 | 20.1 | 12.8 | n/a | 11.8 | 2.1 |
| Solaris / JDK 1.2 | 39.2 | 8.6 | 5.0 | 1.4 | 3.1 | 3.1 |
| Solaris / JDK 1.3 (no JIT) | 2.0 | 1.8 | 1.8 | 1.0 | 1.2 | 1.1 |
| Solaris / JDK 1.3 -client | 19.8 | 1.5 | 1.1 | 1.3 | 2.1 | 1.7 |
| Solaris / JDK 1.3 -server | 1.8 | 2.3 | 53.0 | 1.3 | 4.2 | 3.2 |
public void empty() { }
public Object fetch() { return field; }
public Object singleton() {
if (singletonField == null)
singletonField = new Object();
return singletonField;
}
public Object hashmapGet() {
return hashMap.get("this");
}
public Object create() {
return new Object();
}
q些基准测试也阐明?jin)存在动态编译器的情况下解释性能l果所面(f)的挑战。对?1.3 JDK 在有和没?JIT Ӟ数字上的巨大差异需要给Z些解释。对那些非常单的Ҏ(gu)Q?empty ?fetch Q，基准试的本质（它只是执行一个几乎什么也不做的紧凑的循环Q?JIT 可以动态地~译整个循环Q把q行旉压羃到几乎没有的地步。但在一个实际的E序中，JIT 能否q样做就要取决于很多因素?jin)，所以，?JIT 的计时数据可能在做公q_比时更有用一些。在M情况下，对于更充实的Ҏ(gu)Q?create ?hashmapGet Q，JIT ׃能象Ҏ(gu)单些的方法那样非同步的情况得到巨大的改q。另外，从数据中看不?JVM 是否能够Ҏ(gu)试的重要部分q行优化。同P在可比较?IBM ?Sun JDK 之间的差异反映了(jin) IBM Java SDK 可以更大E度C化非同步的@环，而不是同步版本代h高。这在纯计时数据中可以明昑֜看出Q这里不提供Q?/p>
从这些数字中我们可以得出以下l论Q对非争用同步而言Q虽然存在性能损失Q但在运行许多不是特别微的Ҏ(gu)Ӟ损失可以降到一个合理的水^Q大多数情况下损失大概在 10% ?200% 之间Q这是一个相对较?yu)的数目Q。所以，虽然同步每个Ҏ(gu)是不明智的（q也?x)增加死锁的可能性）(j)Q但我们也不需要这么害怕同步。这里用的单测试是说明一个无争用同步的代仯比创Z个对象或查找一?code>HashMap 的代价小?/p>
׃早期的书c和文章暗示?jin)无争用同步要付出巨大的性能代h(hun)Q许多程序员q全力避免同步。这U恐惧导致了(jin)许多有问题的技术出玎ͼ比如?double-checked lockingQDCLQ。许多关?Java ~程的书和文章都推荐 DCLQ它看上ȝ是避免不必要的同步的一U聪明的Ҏ(gu)Q但实际上它Ҏ(gu)没有用，应该避免使用它。DCL 无效的原因很复杂Q已出?jin)本文讨论的范围Q要深入?jin)解Q请参阅 参考资?/a>里的链接Q?/p>
|
|
假设同步使用正确Q若U程真正参与争用加锁Q?zhn)也能感受到同步对实际性能的媄(jing)响。ƈ且无争用同步和争用同步间的性能损失差别很大Q一个简单的试E序指出争用同步比无争用同步?50 倍。把q一事实和我们上面抽取的观察数据l合在一P可以看出使用一个争用同步的代h(hun)臛_相当于创?50 个对象?/p>
所以，在调试应用程序中同步的用时Q我们应该努力减实际争用的数目Q而根本不是简单地试图避免使用同步。这个系列的W?2 部分把重点攑֜减少争用的技术上Q包括减锁的粒度、减同步块的大以?qing)减线E间׃n数据的数量?/p>
|
|
要(zhn)的E序U程安全Q首先必ȝ定哪些数据将在线E间׃n。如果正在写的数据以后可能被另一个线E读刎ͼ或者正在读的数据可能已l被另一个线E写q了(jin)Q那么这些数据就是共享数据，必须q行同步存取。有些程序员可能?x)惊讶地发现Q这些规则在单地(g)查一个共享引用是否非I的时候也用得上?/p>
许多Z(x)发现q些定义惊hC根{有一U普遍的观点是，如果只是要读一个对象的字段Q不需要请求加锁，其是在 JLS 保证?32 位读操作的原子性的情况下，它更是如此。但不幸的是Q这个观Ҏ(gu)错误的。除非所指的字段被声明ؓ(f) 在确定了(jin)要共享的数据之后Q还要确定要如何保护那些数据。在单情况下Q只需把它们声明ؓ(f) q有一点值得注意的是Q简单地同步存取器方法（或声明下层的字段?
如果一个调用者想要增?
如果两个U程试图同时增加 以上情况是一个很好的CZQ说明我们应该注意多层次_度的数据完整性；同步存取器方法确保调用者能够存取到一致的和最q版本的属性|但如果希望属性的来g当前g_(d)或多个属性间怺一_(d)我们必d步复合操??可能是在一个粗_度的锁上?/p>
volatile Q否?JMM 不会(x)要求下面的^台提供处理器间的~存一致性和序q诏性，所以很有可能，在某些^CQ没有同步就?x)读到陈旧的数据。有x详细的信息，请参?参考资?/a>?/p>
volatile 卛_保护数据字段Q在其它情况下，必须在读或写׃n数据前请求加锁，一个很好的l验是明指Z用什么锁来保护给定的字段或对象，q在你的代码里把它记录下来?/p>
volatile Q可能ƈ不以保护一个共享字Dc(din)可以考虑下面的示例：(x)
private int foo;
public synchronized int getFoo() { return foo; }
public synchronized void setFoo(int f) { foo = f; }foo 属性|以下完成该功能的代码׃是线E安全的Q?/p>
setFoo(getFoo() + 1);foo 属性|l果可能?#160;foo 的值增加了(jin) 1 ?2Q这p时决定。调用者将需要同步一个锁Q才能防止这U争用情况；一个好Ҏ(gu)是在 JavaDoc cM指定同步哪个锁，q样cȝ调用者就不需要自q?jin)?/p>
|
|
有时Q在写一个类的时候，我们q不知道它是否要用在一个共享环境里。我们希望我们的cLU程安全的，但我们又不希望给一个L在单U程环境内用的cd上同步的负担Q而且我们可能也不知道使用q个cL合适的锁粒度是多大。幸q的是，通过提供同步包装Q我们可以同时达C上两个目的。Collections cd是这U技术的一个很好的CZQ它们是非同步的Q但在框架中定义的每个接口都有一个同步包装（例如Q?#160;Collections.synchronizedMap() Q，它用一个同步的版本来包装每个方法?/p>
|
|
虽然 JLS l了(jin)我们可以使我们的E序U程安全的工P但线E安全也不是天上掉下来的馅饼。用同步会(x)蒙受性能损失Q而同步用不当又?x)我们承担数据混ؕ、结果不一致或死锁的风险。幸q的是，在过ȝ几年?JVM 有了(jin)很大的改q，大大减少?jin)与正确使用同步相关的性能损失。通过仔细分析在线E间如何׃n数据Q适当地同步对׃n数据的操作，可以使得(zhn)的E序既是U程安全的，又不?x)承受过多的性能负担?/p>
- (zhn)可以参阅本文在 developerWorks 全球站点上的 英文原文.
- L(fng)?yn)L章顶部或底部?#160;讨论q入?Brian Goetz L的，关于“Java U程Q技巧、窍门和技?#8221;?#160;讨论论坛?#160;
- Jack Shirazi ~写?#160;Java Performance Tuning QO'Reilly & Associates, 2000Q可以ؓ(f)?Java q_上解x能问题提供指导。本书引用的与本书一h供的参考资料提供了(jin)很好?#160;性能调试技?/a>?#160;
- Dov Bulka ?#160;Java Performance and ScalabilityQ第 1 P(x)Server-Side Programming Techniques QAddison-WesleyQ?000Q提供了(jin)大量的设计技巧和诀H，可帮助?zhn)增强自己的应用程序的性能?#160;
- Steve Wilson ?Jeff Kesselman ?#160;Java Platform Performance: Strategies and Tactics QAddison-WesleyQ?000Qؓ(f)有经验的 Java E序员提供了(jin)生成快速、有效的 Java 代码的技术?#160;
- Brian Goetz 最q的著作“ Double-checked locking: Clever, but broken”QJavaWorldQ?001 q?2 月）(j)详细探烦(ch)?JMM q描qC(jin)特定情况下不使用同步的惊人后果?#160;
- 公认的多U程权威 Allen Holub 在他的文?#8220; 警告Q多处理器世界中的线E?/a>”QJavaWorldQ?001 q?2 月）(j)中揭CZ(jin)Z么用于减同步负担的大多数技巧都不v作用?#160;
- Peter Haggar 描述?jin)怎样 用固定的Q@环的序获取多个锁定以避免死?/a>QdeveloperWorksQ?000 q?9 月）(j)?#160;
- 在他的文?#8220; ~写多线E?Java 应用”QdeveloperWorksQ?001 q?9 月）(j)中，Alex Roetter 介绍?Java Thread APIQ概括了(jin)多线E涉?qing)的问题QƈZ般性的问题提供?jin)解x案?#160;
- Doug Lea ?#160;Concurrent Programming in JavaQ第 2 ?/em> QAddison-WesleyQ?999Q是关于 Java 语言中多U程~程的敏感问题的权威书籍?#160;
- “ 同步?Java 内存模型”摘录?Doug Lea 的关?#160;
synchronized的实际意义的著作?#160;
- Bill Pugh ?#160;Java 内存模型为?zhn)学?fn) JMM 提供?jin)一个很好的L(fng)?#160;
- “Double Checked Locking is Broken”声明描述?jin)?f)什?DCL 在用 Java 语言实现时没有用?#160;
- Bill Joy、Guy Steele ?James Gosling ?#160;The Java Language SpecificationQ第 2 ?/em> QAddison-WesleyQ?000Q的W?17 章描qC(jin) Java 内存模型的深层细节问题?#160;
- IBM T.J. Watson 研究中心(j)有一整个目l投入到 性能理中?#160;
- 请在 developerWorks Java 技术专?/a>查找更多的参考资料?#160;
|
||
|
Brian Goetz 是一名Y仉问，q且q去 15 q来一直是专业的Y件开发h员。他?#160;QuiotixQ一家坐落在 Los AltosQCalifornia 的Y件开发和咨询公司的首席顾问。请通过 brian@quiotix.com ?Brian 联系?/p> |
|
]]>