深入理解Java多线程：《Taming Java Threads》精华解读

PDF文件

java

concurrent

线程

threads

下载需积分: 10 | 1.37MB | 更新于2024-07-28 | 134 浏览量 | 举报收藏

立即下载

"Taming Java Threads" 是一本关于Java并发编程的书籍，由Allen Holub撰写，旨在澄清线程的工作原理以及多线程程序中可能出现的困难。书中涵盖了一系列主题，从线程架构到同步机制，再到面向对象的线程设计。在Java并发编程的世界里，了解如何驯服Java线程至关重要。本书首先介绍了线程架构，揭示了为什么所有非简单的Java程序都是多线程的，以及Java的线程支持并不独立于平台这一事实。作者讨论了线程与进程的区别，以及线程安全性和同步的概念，这些都是理解和编写正确并发代码的基础。在"线程的危险"章节中，读者将了解到多线程编程可能带来的问题，如竞态条件、死锁和活锁等。这些问题可能导致程序行为不可预测，甚至完全崩溃。作者通过实例来说明这些潜在的问题，帮助读者建立防范并发问题的意识。接下来，书中深入探讨了互斥量（Mutex）和锁管理，这是实现线程同步的关键工具。互斥量允许一次只有一个线程访问共享资源，而锁管理则涉及如何有效地使用这些锁来防止数据不一致。在"条件变量和计数信号量"章节中，读者会学习到高级同步机制，这些机制允许线程等待特定条件满足后再继续执行，或者控制多个线程的并发访问。 "定时器、警报和Swing线程安全性"章节关注在时间敏感的应用中如何正确地调度线程，以及如何确保Swing这样的GUI组件在多线程环境中保持安全。此外，书中还涵盖了观察者模式和多播器，这些设计模式在处理事件驱动编程和线程通信时非常有用。单例、临界区和读写锁章节则进一步扩展了对同步策略的理解，提供了一种在多个线程之间高效管理资源的方法。最后，书中讨论了面向对象的线程架构，提出了一些改进Java线程模型的设想，为读者提供了构建可扩展和健壮的多线程应用程序的指导。 "Taming Java Threads" 是一本深度剖析Java并发编程的实用指南，适合对并发感兴趣的开发者阅读，有助于提升他们在并发环境下的编程技能和问题解决能力。书中提供的代码示例和实践经验可以帮助读者更好地应对实际项目中的并发挑战。

30:

31: static void print_results( int id )

32: {

33:

34: NumberFormat compositor = NumberFormat.getInstance();

35: compositor.setMaximumFractionDigits( 2 );

36:

37: double time_in_synchronization = locking_time[id] - not_locking_time[id];

38:

39: System.out.println( "Pass " + id + ": Time lost: "

40: + compositor.format( time_in_synchronization )

41: + " ms. "

42: + compositor.format( ((double)locking_time[id]/

not_locking_time[id])*100.0)

43: + "% increase"

44: );

45: }

46:

47: static public void main(String[] args) throws InterruptedException

48: {

49: // First, with no contention:

50:

51: final Synch tester = new Synch();

52: tester.test(0); print_results(0);

53: tester.test(1); print_results(1);

54: tester.test(2); print_results(2);

55: tester.test(3); print_results(3);

56: tester.test(4); print_results(4);

57: tester.test(5); print_results(5);

58: tester.test(6); print_results(6);

59:

60: // Now let's do it again with contention. I'm assuming that

61: // hotspot has optimized the test method by now, so am only

62: // calling it once.

63:

64: final Object start_gate = new Object();

65:

66: Thread t1 = new Thread()

67: { public void run()

68: { try{ synchronized(start_gate) { start_gate.wait(); } }

the bit was not set, it sets it. This instruction is a crude sort of semaphore because when two threads

try to set the bit simultaneously, only one will actually do it. Both threads can then check to see if they

were the one that set the bit.

If the bit is set (i.e., there is contention), the JVM has to go out to the operating system to wait for the

bit to clear. Crossing the interprocess boundary into the operating system is expensive. In NT, it takes

on the order of 600 machine cycles just to enter the OS kernel, and this count doesn't include the

cycles spent doing whatever you entered the kernel to do. That's why passes 7 and 8 take so much

more time, because the JVM must interact with the operating system. Alexander Garthwaite from Sun

Labs brought up a few other interesting issues in a recent email to me:

 Synchronized blocks are often different from synchronized methods in that the generated byte

code need not properly nest these. As a result, these are often slightly more expensive

(particularly in lock-release).

 Some locking strategies use caches of monitors. So, the number and order in which objects are

locked can affect performance. More generally, the locking subsystem may use growable

structures for various purposes, and these will become more cumbersome to manage as the

number of locked objects increases.

 Some locking strategies use a thin-lock/fat-lock strategy. In the thin lock, only simple

synchronization is supported and locking depth is often limited to a small number (often

somewhere between 16 and 64). Lock inflation occurs when this count is exceeded, when there

is contention on the lock, or when a wait or notify operation is performed. Lock deflation can

also add costs if it is supported at all.

 For space efficiency in object headers, other information is often either stored in the same word

as locking state or it forces lock inflation. A common example is the object's hashcode() method.

This means that accessing this information in locked objects is often more expensive, and objects

with hash codes may be more expensive to lock than ones without.

One other thing that I'll add, if you can reduce the odds of contention, then the locking process is more

efficient. This reasoning implies that you should make the synchronization blocks as small as possible

so that a given lock will be unlocked most of the time.

Avoiding Synchronization

Fortunately, explicit synchronization is often avoidable. Methods that don't use any of the state

information (such as fields) of the class to which they belong don't need to be synchronized, for

example. (That is, they use only local variables and arguments—no class-level fields—and they don't

modify external objects by means of references that are passed in as arguments.) There are also

various class-based solutions, which I discuss in subsequent chapters (such as the synchronization

wrappers used by the Java collection classes).

You can sometimes eliminate synchronization simply by using the language properly, however. The

next few sections show you how.

Atomic Energy: Do Not Synchronize Atomic Operations

The essential concept vis-a-vis synchronization is atomicity. An "atomic" operation cannot be

interrupted by another thread, and naturally atomic operations do not need to be synchronized.

Java defines a few atomic operations. In particular, assignment to variables of any type except long

and double is atomic. To understand ramifications of this statement, consider the following (hideously

non-object-oriented) code:

class Unreliable

{ private long x;

public long get_x( ){ return x; }

public void set_x(long value ){ x = value; }

}

Thread one calls:

obj.set_x( 0 );

A second thread calls:

obj.set_x( 0x123456789abcdef );

The problem is the innocuous statement:

x = value;

which is effectively treated by the JVM as two separate 32-bit assignments, not a single 64-bit

assignment:

x.high_word = value.high_word;

x.low_word = value.low_word;

Either thread can be interrupted by the other halfway through the assignment operation—after

modifying the high word, but before modifying the low word. Depending on when the interruption

occurs (or if it occurs), the possible values of x are 0x0123456789abcdef, 0x0123456700000000,

0x0000000089abcdef, or 0x0000000000000000. There's no telling which one you'll get. The only

way to fix this problem is to redefine both set_x() and get_x() as synchronized or wrap the assignment

in a synchronized block.

The volatile Keyword

Another keyword of occasional interest is volatile. The issue here is not one of synchronization,

but rather of optimization. If one method sets a flag, and another tests it, the optimizer might

think that the value of the flag never changes and optimize the test out of existence. Declaring the

variable as volatile effectively tells the optimizer not to make any assumptions about the

variable's state. In general, you'll need to use volatile only when two threads both access a public

flag, something that shouldn't happen in well-crafted OO systems. In any event, for reasons that I

don't want to go into here, volatile can behave in unpredictable ways on multiprocessor machines.

Until the Java language specification is fixed, it's best to use explicit synchronization to avoid

these problems.

Fortunately, this problem doesn't arise with 32-bit (or smaller) variables. That is, if all that a method

does is set or return a value, and that value is not a long or double, then that method doesn't have to be

synchronized. Were the earlier x redefined as an int, no synchronization would be required.

Bear in mind that only assignment is guaranteed to be atomic. A statement like x=++y (or x+=y) is

never thread safe, no matter what size x and y are. You could be preempted after the increment but

before the assignment. You must use the synchronized keyword to get atomicity in this situation.

Race Conditions

Formally, the sort of bug I just described—when two threads simultaneously contend for the same

object and, as a consequence, leave the object in an undefined state—is called a race condition. Race

conditions can occur anywhere that any sequence of operations must be atomic (not preemptable), and

you forget to make them atomic by using the synchronized keyword. That is, think of synchronized as

a way of making complex sequences of operations atomic, in the same way that assignment to a

boolean is atomic. The synchronized operation can't be preempted by another thread that's operating

on the same data.

Immutability

An effective language-level means of avoiding synchronization is immutability. An immutable object

is one whose state doesn't change after it's created. A Java String is a good example—there's no way

to modify the String once it's created. (The expression string1 += string2 is actually treated like

string1 = string1 + string2; a third string is created by concatenating the two operands, then the target

is overwritten to reference this third string. As usual, this operation is not atomic.)

Since the value of an immutable object never changes, multiple threads can safely access the object

simultaneously, so no synchronization is required.

Create an immutable object by making all of the fields of a class final. The fields don't all have to be

initialized when they are declared, but if they aren't they must be explicitly initialized in every

constructor. For example:

class I_am_immutable

{ private final int MAX_VALUE = 10;

private final int blank_final;

public I_am_immutable( int initial_value )

{ blank_final = initial_value;

}

A final field that's initialized by the constructor in this way is called a blank final.

In general, if you are accessing an object a lot, but not modifying it much, making it immutable is a

good idea since none of the methods of the object's class need to be synchronized. If you modify the

object a lot, however, the overhead of copying the object will be much higher than the overhead of

synchronization, so an immutable-object approach doesn't make sense. Of course, there is a vast gray

area where neither approach is obviously better.

Synchronization Wrappers

Often it's the case that you need synchronization sometimes, but not all the time. A good example is

the Java 2 Collection classes. Typically, collections will be accessed from within synchronized

methods, so it would be contraindicated for the methods of the collection to be synchronized, since

you'd be unnecessarily acquiring two locks (the one on the object that used the collection and the

other on the collection itself). Java's solution to this problem is generally applicable: use a

synchronization wrapper. The basic notion of the Gang-of-Four Decorator design pattern is that a

Decorator both implements some interface and also contains an object that implements the same

interface. (The "Gang-of-Four" referenced in the previous sentence are Erich Gamma, Richard Helm,

Ralph Johnson, and John Vlissides, the authors of the excellent book Design Patterns: Elements of

Reusable Object-Oriented Software [Reading: Addison Wesley, 1995].) The container implements the

same methods as the contained object, but modifies the behavior of the method as it passed the

request through to the contained object. The classes in the java.io package are all Decorators: A

BufferedInputStream both implements InputStream and contains an instance of some InputStream—

you talk to the contained object through the container, which modifies the behavior of the contained

object. (The read() method buffers characters in the BufferedInputStream decorator and doesn't buffer

剩余295页未读，继续阅读

泥瓦匠1024

粉丝: 283

深入理解Java多线程：《Taming Java Threads》精华解读

Java应用日志框架TNT4J.zip

StopwatchApp:CP3406 Prac03的秒表实用程序应用程序

！！！！ap6212a0_a33_sc3817r_验证通过_修正wifi的配置文件为nvram_ap6212.txt

ap6212a0_a33_sc3817r_服务器验证通过_bt已经通了_wifi需要修改配置_需要再次验证_20170626_1549.7z

ap6212a0_a33_sc3817r_神舟验证版本_借用nvram_ap6210这个配置文件_20170626_1834没有外层目录.7z

Visual C++ 编程资源大全（英文源码 其它）

掌握Arduino多任务处理：FreeRTOS全指南

Innovus脚本自动化：掌握IEEE 1801标准下的脚本编写艺术

Unveiling MySQL Deadlock Issues: How to Analyze and Completely Solve

压力测试在软件测试中的应用

最新资源

Visual C++ 编程资源大全（英文源码其它）