Java并发编程实战指南：解锁多线程安全与性能优化

需积分: 10 70 浏览量更新于2024-07-22 收藏 6.36MB PDF 举报

《Java并发编程实践指南》(Java Concurrency in Practice)是由Brian Götz、Tim Peierls、Joshua Bloch、Joseph Bowbeer、David Holmes和Doug Lea等知名专家共同编著的专业书籍，由Addison-Wesley Professional出版社出版。该书的ISBN号分别为10位：0321349601和13位：9780321349606。本书旨在帮助读者深入了解Java并发编程的相关概念、技术和策略，解决在多线程环境下面临的挑战。 1. **章节概览** - **第1章：引言** 提供了对并发编程的简短历史回顾，强调了多线程带来的益处，包括利用多处理器提高性能、简化模型设计、处理异步事件的便捷性以及改善用户界面的响应性。同时，也提到了并发编程的风险，包括安全、可用性和性能问题。 - **第2章：线程安全** 详细探讨了什么是线程安全，以及原子性（保证操作不可分割）的重要性。本章还涵盖了锁定机制，如何使用锁来保护共享状态，并讨论了线程安全与性能之间的平衡。 - **第3章：共享对象与同步** 进一步深入到共享资源的管理和同步，解释了如何通过互斥锁和条件变量来确保正确地访问和控制共享数据。 2. **核心主题** - **并发编程基础**：讲解了并发编程的核心概念，如线程、任务调度、并发数据结构等，以及它们在现代多核处理器环境下的应用。 - **线程安全性**：讨论了如何避免竞态条件、死锁和活锁等问题，通过例子展示如何设计和实现线程安全的代码。 - **并发工具与框架**：介绍Java标准库中的并发工具，如synchronized、volatile、ExecutorService和Future等，以及它们在实际项目中的使用场景。 - **并发设计原则**：提供最佳实践，如避免过度锁定、使用不可变对象减少竞争、以及何时选择并行计算或异步处理。 3. **实用价值** - **适合人群**：这本书适合Java开发者，特别是那些希望提升并发编程技能、理解和解决多线程问题的程序员，无论是在初学者阶段还是高级开发者的进阶学习。 - **实操指导**：书中包含大量的代码示例和实践案例，使读者能够在阅读过程中逐步掌握并发编程的技巧。《Java并发编程实践》是一本全面且深入的参考书籍，它不仅涵盖了理论知识，还提供了丰富的实战经验，是任何想要在并发编程领域取得成功的技术人员不可或缺的资源。



2

JavaConcurrencyInPractice

1.1.A(Very)BriefHistoryofConcurrency

Intheancientpast,computers didn't haveoperating systems; they executeda single programfrombeginningtoend,

andthatpro gramhaddirectaccesstoalltheresourcesofthemachine.Notonlywasitdifficulttowriteprogramsthat

ran on the bare metal, but running only a single program at a time was an inefficient use of ex

pensive and scarce

computerresources.

Operatingsystems evolvedtoallowmorethanone programtorunatonce,runningindividualprogramsinprocesses:

isolated, independently executing programs to which the operating system allocates resources such as memory, file

handles,and securitycredentials.Iftheyneede

dto,processescouldcommunicatewithoneanotherthrough avariety

ofcoarsegrainedcommunicationmechanisms:sockets,signalhandlers,sharedmemory,semaphores,andfiles.

Several motivating factors led to the development of operating systems that allowed multiple programs to execute

simultaneously:

Resource utilization. Programs sometimes have to wait for ex

ternal operations such as input or output, and while

waitingcandonousefulwork.Itismoreefficienttousethatwaittimetoletanotherprogramrun.

Fairness. Multiple users and programs  may have equal claims on the machine's resources. It is preferable to let them

sharethecomputerviafinergraine

dtimeslicingthantoletoneprogramruntocompletionandthenstartanother.

Convenience. It is often easier or more desirable to write sever

al programs that each perform a single task and have

themcoordinatewitheachotherasnecessarythantowriteasingleprogramthatperformsallthetasks.

Inearlytimesharingsystems,each processwasavirtual vonNeumanncomputer;ithad ame

moryspace storingboth

instructions and data, executing instructions sequentially according to the semantics of the machine language, and

interacting with the outside world via the operating system through a set of I/O primitives. For each instruction

executedtherewasaclearlydefined"nextinstruction",andcontrolflowedthroughtheprogramaccordingtother

ules

oftheinstructionset.Nearlyallwidelyusedprogramminglanguagestodayfollowthissequentialprogrammingmodel, 

wherethelanguagespecificationclearlydefines"whatcomesnext"afteragivenactionisexecuted.

Thesequentialprogrammingmodelisintuitiveandnatural,asitmodelsthewayhumanswor

k:doonethingatatime,

in sequence mostly. Get out of bed, put on your bathrobe, go downstairs and start the tea. As in programming

languages, each of these realworld actions is an  abstraction for a sequence of finergrained actionsopen the

cupboard,selectaflavoroftea,measuresometeaintothepot,seeifthere'senoughwaterinthetea

kettle,ifnotput

somemorewaterin,setitonthestove,turnthestoveon,waitforthewatertoboil,andsoon.Thislaststepwaiting

forthewatertoboilalsoinvolvesadegreeofasynchrony.Whilethewaterisheating,youhaveachoiceofwhattodo

just wait, or do other tasks in that time such as starting th

e toast (another asynchronous task) or fetching the

newspaper, while remaining aware that your attention will so on be needed by the t

eakettle. The manufacturers of

teakettlesandtoasterskn owtheirproductsareoftenusedinanasynchronousmanner,sotheyraiseanaudiblesignal

when they complete their task. Finding the right balance of sequentiality and asynchrony is often a characteristic of

efficientpeopleandthesameistrueofprograms.

Thesameco

ncerns(resourceutilization,fairness,andconvenience)thatmotivatedthedevelopmentofprocessesalso

motivated the development of threads. Threads allow multiple streams of program control flow to coexist within a

process. They share processwide reso urces such as memory and file handles, but each thread has its own progra m

counter,stack,andlocalva

riables.Threadsalsoprovideanaturaldecompositionforexploitinghardwareparallelismon 

multiprocessorsystems;multiplethreadswithinthesameprogramcanbescheduledsimultaneouslyonmultipleCPUs.

Threadsaresometimescalledlightweightprocesses,andmostmodernoperatingsystemstreatthreads,notprocesses,

as the basic units of scheduli

ng. In the absence of explicit coordination, threads execute simultaneously and

asynchronouslywithrespecttooneanother.Sincethreadssharethememoryaddressspaceoftheirowningprocess,all

threadswithinaprocesshaveaccesstothesamevariables andallocateobjectsfromthesameheap,whichallowsfiner

grained da

ta sharing than interprocess mechanisms. But without explicit synchronization to coordinate access to

shareddata,athreadmaymodifyvariablesthatanotherthreadisinthemiddleofusing,withunpredictableresults.



3

3BChapter1 Introduction11B1.2.BenefitsofThreads

1.2.BenefitsofThreads

Whenusedproperly,threadscanreducedevelopmentandmaintenancecostsandimprovetheperformanceofcomplex 

applications.Threadsmakeiteasiertomodelhowhumansworkandinteract,byturningasynchronousworkflowsinto

mostly sequential ones. They can also turn otherwise convoluted code into  straightline code that is easier to write,

read,andma

intain.

ThreadsareusefulinGUIapplicationsforimprovingtheresponsivenessoftheuserinterface,andinserverapplications

for improving resource utilization and throughput. They also simplify the implementation of the JVMthe garbage

collector usually runs in one or more dedicated threads. Most nontrivial Java applications rely to so

me degree on

threadsfortheirorganization.

1.2.1.ExploitingMultipleProcessors

Multiprocessor systems used to be expensive and rare, found only in large data centers and scientific computing

facilities.Todaytheyarecheapand plentiful;evenlowendserverandmidrangedesktop systemsoftenhavemultiple

processors.Thistrendwillonlyaccelerate;asitgetshardertoscaleupclockrates,processormanufactur

erswillinstead

put more processor cores on a single chip. All the major chip manufacturers have begun this transition, and we are

alreadyseeingmachineswithdramaticallyhigherprocessorcounts.

Sincethebasicunitofschedulingisthethread,aprogramwith onlyonethreadcanrunonatmostoneprocessorata

time.Onatw

oprocessorsystem,asinglethreadedprogramisgivingupaccesstohalftheavailableCPUresources;ona

100processor system, it is giving up access to 99%. On the other hand, programs with multiple active threads can

execute simultaneously on multiple processors. When prope

rly designed, multithreaded programs can improve

throughputbyutilizingavailableprocessorresourcesmoreeffectively.

Using multiple threads can also help achieve better throughput on singleprocessor systems. If a prog ram is single

threaded, the processor remains idle  while it waits for a synchronous I/O operation to complete. In a multithr

eaded

program,anotherthreadcanstillrunwhilethefirstthreadiswaitingfortheI/Otocomplete,allowingtheapplicationto

stillmakeprogressduringtheblockingI/O.(Thisis likereadingthenewspaperwhilewaitingforthewatertoboil,rather

thanwaitingforthewatertoboilbefor

estartingtoread.)

1.2.2.SimplicityofModeling

It is often easier to manage your time when you have only one type of task to perform (fix these twelve bugs) than

when you have several (fix the bugs, interview replacement candidates for the system administrator, complete your

team'sperformanceevaluations,andcreatetheslidesforyourpresentationnextweek).Wh

enyouhaveonlyonetype

of task to do, youcanstartat the top of thepile andkeep working until thepile is exhausted (or you are); you don't

haveto spend any mental energy fi guring out what to work on next.On the otherhand, managingmultiple prioriti

es

anddeadlinesandswitchingfromtasktotaskusuallycarriessomeoverhead.

The same is true for software: a program that pro cesses one type of task sequentially is simpler to write, less error

prone,andeasiertotestthanonemanagingmultipledifferenttypesoftasksatonce.Assigningathreadtoeachtypeof

taskortoeachelementinasimulationaffordstheill

usionofsequentialityandinsulatesdomainlogicfromthedetails of

scheduling, interleaved operations, asynchronous I/O, and resourcewaits.A complicated, asynchronous workflow can

be decomposed into anumber of simpler, synchronousworkflowseach running in aseparate thread, i

nteracting only

witheachotheratspecificsynchronizationpoints.

This benefit is often exploited by frameworks such as servlets or RMI (Remote Method Invocation). The framework

handles the details of request management, thread creation, and load balancing, dispatching portions of the request

handling to the appropriate applica

tion component at the appropriate point in the workflow. Servlet writers do not

needtoworryabouthowmanyotherrequestsarebeingprocessedatthesametimeorwhetherthesocketinputand

output streams block; when a servlet's

service method is called in response to a web request, it can process  the

requestsynchronously as if it were a singlethreaded program. Thiscan simplify compone nt developmentandreduce

thelearningcurveforusingsuchframeworks.

1.2.3.SimplifiedHandlingofAsynchronousEvents

Aserverapplicationthatacceptssocketconnectionsfrommultipleremoteclientsmaybeeasiertodevelopwheneach

connectionisallocateditsownthreadandallowedtousesynchronousI/O.



4

JavaConcurrencyInPractice

If an application goes to read from a socket when no data is available,

read blocks until some data is available. In a

singlethreadedapplication,thismeansthatnotonlydoesprocessingthecorrespondingrequeststall,butprocessingof

all requests stalls while the single thread is blocked. To avoid this problem, singlethreaded server applications are

forcedtousenonblockingI/O,whichisfarmorecomplica

tedanderrorpronethansynchronous I/O.However,ifeach

requesthasitsownthread,thenblockingdoesnotaffecttheprocessingofotherrequests.

Historically,operatingsystemsplacedrelativelylowlimitsonthenumberofthreadsthataprocesscouldcreate,asfew

asseveralhundred(or ev

enless).Asaresult,operatingsystemsdevelopedefficientfacilitiesformultiplexedI/O,such

as the Unix

select and poll system calls, and to access these facilities, the Java class libraries acquired a set of

packages (

java.nio) for nonblocking I/O. However, operating system support for larger numbers of threads has 

improved significantly, making the threadperclient model practical eve n for large numbers of clients on some

platforms.

[1]



[1]TheNPTLthreadspackage,nowpartofmostLinuxdistributions,wasdesignedtosupporthundredsofthousandsofthreads.NonblockingI/O

hasitsownbenefits,butbetterOSsupportforthreadsmeansthattherearefewersituationsforwhichitisessential.

1.2.4.MoreResponsiveUserInterfaces

GUIapplicationsusedtobesinglethreaded,whichmeantthatyouhadtoeitherfrequentlypollthroughoutthecodefor

input events (which is messy and intrusive) or execute all application code indirectly through a "main event loop". If

codecall ed fromthemaineventlooptakestoolongtoexecute,the userinte

rfaceappearsto"freeze"until thatcode

finishes,becausesubsequentuserinterfaceeventscannotbeprocesseduntilcontrolisreturnedtothemaineventloop.

Modern GUI frameworks, such as the AWT and Swing toolkits, replace the main event loop with an event dispatch

thread(EDT).Whenauserinterfaceev

entsuchasabutton pressoccurs,applicationdefinedeventhandlersarecalled

in the event thread. Most GUI frameworks are singlethreaded subsystems, so the main event loop is effectively still

present,butitrunsinitsownthreadunderthecontroloftheGUItoolkitratherthanth

eapplication.

Ifonlyshortlivedtasksexecutein theeventthread,theinterface remainsresponsivesincetheeventthreadisalways

able to process user actions reasonably quickly. However, processinga longrunning task in the event thread, such as

spellchecking alarge documentorfetchingaresourceoverthe network,impairsresponsiveness.Iftheuserperfor

ms

anactionwhilethistaskisrunning,thereisalongdelaybeforetheeventthreadcanprocessorevenacknowledgeit.To

addinsulttoinjury,notonlydoestheUIbecomeunresponsive,butitisimposs ibletocanceltheoffendingtaskevenif

theUIprovid

esacancelbuttonbecausetheeventthreadisbusyandcannothandlethecancelbuttonpresseventuntil

the lengthy task complet es! If, however, the longrunning task is instead executed in a separate thread, the event

threadremainsfreetoprocessUIevents,makingth

eUImoreresponsive.

剩余233页未读，继续阅读

xueyuliuyun_du

粉丝: 0
资源: 7

Java并发编程实战指南：解锁多线程安全与性能优化

JAVA并发编程实践

3_Java_Concurrency_in_Practice_proglib_java_practice_

java_concurrency_in_practice:《Java并发编程实战》学习Demo

java_concurrency_in_practice_source源代码

Java Concurrency in Practice Java并发编程

Java_Concurrency_in_Practice

java_concurrency_in_practice

Java并发编程实践 java concurrency in practice

Java_Concurrency_in_Practice.pdf

Java并发编程实践（Java Concurrency in Practice） （中英版）

最新资源

Java并发编程实践（Java Concurrency in Practice）（中英版）