JCIP思維導圖-1-Introduction

1-Introduction
start
threads are the easiest way to tap the computing power of multiprocessor systems
Writing correct concurrent programs is very hard.
1.1-a brief history of concurrency
Resource utilization
Fairness
Convenience
The sequential programming model is intuitive and natural,as it models the way humans work
multiplle threads within the same program can be scheduled simultaneously on multiple CPUs
But without explicit synchronization to coordinate access to shared data,a thread may modify variables that another program is in the middle of using,with unpredictable results
1.2-Benefits of threads
1.2.1-Exploiting multiple processors
1.2.2-Simplicity of modeling
as it gets hard to scale-up clock rates,processor manufactureers will instead put more processor cores on a single chip.
The basic unit of scheduling is the thread,a program with only 1 thread can run on at most 1 processor at a time.on a 100-processor system,it is giving up access to 99%
allowing the application to still make progress during the blocking I/O(This is like reading the newspaper while waiting the water to boil,rather than waiting for the water to boil before starting to read)
1.2.3-Simplified handling of asynchronous events
operating system support for large number of threads has improved significantly,making the thread-per-client model practical even for large numbers of clients on some platforms
1.2.4-More responsive user interfaces
replace the main event loop with an event dispatch thread(EDT)
1.3-Risk of threads
1.3.1-Safety hazards
Nothing bad ever happens, i.e. program correctness is guaranteed irrespective of interleaved execution
threads is a double-edged sword
a formal cross-platform memory model(it is this formal cross-platform memory model that makes possible the development of write-once,run-anywhere concurrent applications in Java)
the ordering of operations in multiple threads is unpredictable and sometimes surprising
two threads could call getNext and receive the same value.Since threads may be arbitrarily interleaved by the runtime,it is possible for two threads to read the value at the same time
in the absence of synchronization,the compiler,hardware,and runtime are allowed to take substantial liberties with the timing and ordering of actions,such as caching variable in registers or processor-local caches where they are temporarily(or even permanently) invisible to other threads
1.3.2-Liveness hazards
safety cannot be compromised
use of threads introduces additional safety hazards not present in single-threaded programs.
“liveness”:something good eventually happens eg: no deadlock
1.3.3-Performance hazards
Something good happens fast enough. For eg: no excessive context switches.
they must use synchronization mechanisms that can inhibit compiler optimizations,flush or invalidate memory caches,and create synchronization traffic on the shared memory bus
1.4-Threads are everywhere
Timer
it would be nice to believe that concurrency is an optional or advanced language feature,but the reality is that nearly all java applications are multithreaded
Framework introduce concurrency into applications by calling application components from framework threads. Components invariably access application state,thus requiring that all code paths accessing that state be thread-safe
Servlets and JSPs
Remote Method Invocation
Swing and AWT
Many Java frameworks (GUI toolkits, RMI, Timers, etc) internally use threads. So your code must be thread-safe even if you do not explicitly use threads.
start
threads are the easiest way to tap the computing power of multiprocessor systems
Writing correct concurrent programs is very hard.
1.1-a brief history of concurrency
Resource utilization
Fairness
Convenience
The sequential programming model is intuitive and natural,as it models the way humans work
multiplle threads within the same program can be scheduled simultaneously on multiple CPUs
But without explicit synchronization to coordinate access to shared data,a thread may modify variables that another program is in the middle of using,with unpredictable results
1.2-Benefits of threads
1.2.1-Exploiting multiple processors
1.2.2-Simplicity of modeling
as it gets hard to scale-up clock rates,processor manufactureers will instead put more processor cores on a single chip.
The basic unit of scheduling is the thread,a program with only 1 thread can run on at most 1 processor at a time.on a 100-processor system,it is giving up access to 99%
allowing the application to still make progress during the blocking I/O(This is like reading the newspaper while waiting the water to boil,rather than waiting for the water to boil before starting to read)
1.2.3-Simplified handling of asynchronous events
operating system support for large number of threads has improved significantly,making the thread-per-client model practical even for large numbers of clients on some platforms
1.2.4-More responsive user interfaces
replace the main event loop with an event dispatch thread(EDT)
1.3-Risk of threads
1.3.1-Safety hazards
Nothing bad ever happens, i.e. program correctness is guaranteed irrespective of interleaved execution
threads is a double-edged sword
a formal cross-platform memory model(it is this formal cross-platform memory model that makes possible the development of write-once,run-anywhere concurrent applications in Java)
the ordering of operations in multiple threads is unpredictable and sometimes surprising
two threads could call getNext and receive the same value.Since threads may be arbitrarily interleaved by the runtime,it is possible for two threads to read the value at the same time
in the absence of synchronization,the compiler,hardware,and runtime are allowed to take substantial liberties with the timing and ordering of actions,such as caching variable in registers or processor-local caches where they are temporarily(or even permanently) invisible to other threads
1.3.2-Liveness hazards
safety cannot be compromised
use of threads introduces additional safety hazards not present in single-threaded programs.
“liveness”:something good eventually happens eg: no deadlock
1.3.3-Performance hazards
Something good happens fast enough. For eg: no excessive context switches.
they must use synchronization mechanisms that can inhibit compiler optimizations,flush or invalidate memory caches,and create synchronization traffic on the shared memory bus
1.4-Threads are everywhere
Timer
it would be nice to believe that concurrency is an optional or advanced language feature,but the reality is that nearly all java applications are multithreaded
Framework introduce concurrency into applications by calling application components from framework threads. Components invariably access application state,thus requiring that all code paths accessing that state be thread-safe
Servlets and JSPs
Remote Method Invocation
Swing and AWT
Many Java frameworks (GUI toolkits, RMI, Timers, etc) internally use threads. So your code must be thread-safe even if you do not explicitly use threads.