Go语言并发编程指南：开发者工具与技术

需积分: 5 134 浏览量更新于2024-07-15 收藏 5.54MB PDF 举报

《并发编程在Go》是一本由Katherine Cox-Buday撰写的专业技术书籍，专为开发者提供工具和技术指南，深入探讨了Go语言中的并发特性。Go，由Google开发的一种开源编程语言，以其简洁的语法和高效的并发支持而闻名。本书旨在帮助读者理解和利用Go语言的强大并发能力，以提升软件性能和可扩展性。在《Concurrency in Go》中，作者详细解析了Go的并发模型Goroutines（轻量级线程）和Channels（通信机制），这些都是Go语言的核心概念。Goroutines通过调度器实现非阻塞式并发，允许代码在同一时刻执行多个任务，而不会消耗过多系统资源。Channels则用于在这些并发任务间安全地传递数据，提供了同步和通信的关键工具。书中还会涵盖Go的并发控制结构，如Mutexes（互斥锁）、RWMutexes（读写锁）和WaitGroups，这些有助于处理并发操作的同步问题，防止数据竞争和死锁。此外，作者还会讨论Go的并发原语，如select和sync包，以及如何利用它们设计高效的并发算法和并发程序。《Concurrency in Go》还涉及了高级主题，如错误处理、死锁检测和资源管理，以及如何利用Go的异步编程特性进行高效编程。此外，书末的章节可能包括最佳实践、性能优化策略和案例研究，以帮助读者在实际项目中应用所学知识。该书适合已有一定编程基础，尤其是对Go语言感兴趣的开发者阅读，无论你是初学者还是进阶者，都能从中获益匪浅。它不仅提供了理论知识，而且结合了实战示例，使读者能够快速掌握并运用Go语言在并发编程方面的精髓。作为一本版权受保护的作品，版权属于Katherine Cox-Buday，版权所有。O'Reilly Media公司出版，适用于教育、商业或销售推广用途。在线版本也提供，更多详情可通过O'Reilly官网查询。本书的编辑、生产编辑、校对人员等都为确保内容质量做出了贡献，确保了读者能够获得准确无误且实用的并发编程指导。

rants careful study, and—most importantly—the idea that despite these challenges,

Go can make programs clearer and faster by using its concurrency primitives.

As with most paths toward understanding, we’ll begin with a bit of history. Let’s first

take a look at how concurrency became such an important topic.

Moore’s Law, Web Scale, and the Mess We’re In

In 1965, Gordon Moore wrote a three-page paper that described both the consolida‐

tion of the electronics market toward integrated circuits, and the doubling of the

number of components in an integrated circuit every year for at least a decade. In

1975, he revised this prediction to state that the number of components on an inte‐

grated circuit would double every two years. This prediction more or less held true

until just recently—around 2012.

Several companies foresaw this slowdown in the rate Moore’s law predicted and

began to investigate alternative ways to increase computing power. As the saying

goes, necessity is the mother of innovation, and so it was in this way that multicore

processors were born.

This looked like a clever way to solve the bounding problems of Moore’s law, but

computer scientists soon found themselves facing down the limits of another law:

Amdahl’s law, named after computer architect Gene Amdahl.

Amdahl’s law describes a way in which to model the potential performance gains

from implementing the solution to a problem in a parallel manner. Simply put, it

states that the gains are bounded by how much of the program must be written in a

sequential manner.

For example, imagine you were writing a program that was largely GUI based: a user

is presented with an interface, clicks on some buttons, and stuff happens. This type of

program is bounded by one very large sequential portion of the pipeline: human

interaction. No matter how many cores you make available to this program, it will

always be bounded by how quickly the user can interact with the interface.

Now consider a different example, calculating digits of pi. Thanks to a class of algo‐

rithms called spigot algorithms, this problem is called embarrassingly parallel, which

—despite sounding made up—is a technical term which means that it can easily be

divided into parallel tasks. In this case, significant gains can be made by making more

cores available to your program, and your new problem becomes how to combine

and store the results.

Amdahl’s law helps us understand the difference between these two problems, and

can help us decide whether parallelization is the right way to address performance

concerns in our system.

2 | Chapter 1: An Introduction to Concurrency

For problems that are embarrassingly parallel, it is recommended that you write your

application so that it can scale horizontally. This means that you can take instances of

your program, run it on more CPUs, or machines, and this will cause the runtime of

the system to improve. Embarrassingly parallel problems fit this model so well

because it’s very easy to structure your program in such a way that you can send

chunks of a problem to different instances of your application.

Scaling horizontally became much easier in the early 2000s when a new paradigm

began to take hold: cloud computing. Although there are indications that the phrase

had been used as early as the 1970s, the early 2000s are when the idea really took root

in the zeitgeist. Cloud computing implied a new kind of scale and approach to appli‐

cation deployments and horizontal scaling. Instead of machines that you carefully

curated, installed software on, and maintained, cloud computing implied access to

vast pools of resources that were provisioned into machines for workloads on-

demand. Machines became something that were almost ephemeral, and provisioned

with characteristics specifically suited to the programs they would run. Usually (but

not always) these resource pools were hosted in data centers owned by other compa‐

nies.

This change encouraged a new kind of thinking. Suddenly, developers had relatively

cheap access to vast amounts of computing power that they could use to solve large

problems. Solutions could now trivially span many machines and even global regions.

Cloud computing made possible a whole new set of solutions to problems that were

previously only solvable by tech giants.

But cloud computing also presented many new challenges. Provisioning these resour‐

ces, communicating between machine instances, and aggregating and storing the

results all became problems to solve. But among the most difficult was figuring out

how to model code concurrently. The fact that pieces of your solution could be run‐

ning on disparate machines exacerbated some of the issues commonly faced when

modeling a problem concurrently. Successfully solving these issues soon led to a new

type of brand for software, web scale.

If software was web scale, among other things, you could expect that it would be

embarrassingly parallel; that is, web scale software is usually expected to be able to

handle hundreds of thousands (or more) of simultaneous workloads by adding more

instances of the application. This enabled all kinds of properties like rolling upgrades,

elastic horizontally scalable architecture, and geographic distribution. It also intro‐

duced new levels of complexity both in comprehension and fault tolerance.

And so it is in this world of multiple cores, cloud computing, web scale, and problems

that may or may not be parallelizable that we find the modern developer, maybe a bit

overwhelmed. The proverbial buck has been passed to us, and we are expected to rise

to the challenge of solving problems within the confines of the hardware we’ve been

handed. In 2005, Herb Sutter authored an article for Dr. Dobb’s, titled, “The free lunch

Moore’s Law, Web Scale, and the Mess We’re In | 3

Here, lines 3 and 5 are both trying to access the variable data, but there is no guaran‐

tee what order this might happen in. There are three possible outcomes to running

this code:

•

Nothing is printed. In this case, line 3 was executed before line 5.

•

“the value is 0” is printed. In this case, lines 5 and 6 were executed before line 3.

• “the value is 1” is printed. In this case, line 5 was executed before line 3, but line 3

was executed before line 6.

As you can see, just a few lines of incorrect code can introduce tremendous variability

into your program.

Most of the time, data races are introduced because the developers are thinking about

the problem sequentially. They assume that because a line of code falls before another

that it will run first. They assume the goroutine above will be scheduled and execute

before the data variable is read in the if statement.

When writing concurrent code, you have to meticulously iterate through the possible

scenarios. Unless you’re utilizing some of the techniques we’ll cover later in the book,

you have no guarantees that your code will run in the order it’s listed in the source‐

code. I sometimes find it helpful to imagine a large period of time passing between

operations. Imagine an hour passes between the time when the goroutine is invoked,

and when it is run. How would the rest of the program behave? What if it took an

hour between the goroutine executing successfully and the program reaching the if

statement? Thinking in this manner helps me because to a computer, the scale may be

different, but the relative time differentials are more or less the same.

Indeed, some developers fall into the trap of sprinkling sleeps throughout their code

exactly because it seems to solve their concurrency problems. Let’s try that in the pre‐

ceding program:

1 var data int

2 go func() { data++ }()

3 time.Sleep(1*time.Second) // This is bad!

4 if data == 0 {

5 fmt.Printf("the value is %v.\n" data)

6 }

Have we solved our data race? No. In fact, it’s still possible for all three outcomes to

arise from this program, just increasingly unlikely. The longer we sleep in between

invoking our goroutine and checking the value of data, the closer our program gets to

achieving correctness—but this probability asymptotically approaches logical correct‐

ness; it will never be logically correct.

In addition to this, we’ve now introduced an inefficiency into our algorithm. We now

have to sleep for one second to make it more likely we won’t see our data race. If we

Why Is Concurrency Hard? | 5

utilized the correct tools, we might not have to wait at all, or the wait could be only a

microsecond.

The takeaway here is that you should always target logical correctness. Introducing

sleeps into your code can be a handy way to debug concurrent programs, but they are

not a solution.

Race conditions are one of the most insidious types of concurrency bugs because they

may not show up until years after the code has been placed into production. They are

usually precipitated by a change in the environment the code is executing in, or an

unprecedented occurrence. In these cases, the code seems to be behaving correctly,

but in reality, there’s just a very high chance that the operations will be executed in

order. Sooner or later, the program will have an unintended consequence.

Atomicity

When something is considered atomic, or to have the property of atomicity, this

means that within the context that it is operating, it is indivisible, or uninterruptible.

So what does that really mean, and why is this important to know when working with

concurrent code?

The first thing that’s very important is the word “context.” Something may be atomic

in one context, but not another. Operations that are atomic within the context of your

process may not be atomic in the context of the operating system; operations that are

atomic within the context of the operating system may not be atomic within the con‐

text of your machine; and operations that are atomic within the context of your

machine may not be atomic within the context of your application. In other words,

the atomicity of an operation can change depending on the currently defined scope.

This fact can work both for and against you!

When thinking about atomicity, very often the first thing you need to do is to define

the context, or scope, the operation will be considered to be atomic in. Everything

follows from this.

Fun Fact

In 2006, the gaming company Blizzard successfully sued MDY Industries for

$6,000,000 USD for making a program called “Glider,” which would automatically

play their game, World of Warcraft, without user intervention. These types of pro‐

grams are commonly referred to as “bots” (short for robots).

At the time, World of Warcraft had an anti-cheating program called “Warden,” which

would run anytime you played the game. Among other things, Warden would scan

the memory of the host machine and run a heuristic to look for programs that

appeared to be used for cheating.

6 | Chapter 1: An Introduction to Concurrency

剩余236页未读，继续阅读

good006cs

粉丝: 0
资源: 16

Go语言并发编程指南：开发者工具与技术

concurrency-in-go pdf epub azw3

Concurrency in Go: Tools and Techniques for Developers

Go in Practice.pdf

Goroutines: Understanding Parallelism vs. Concurrency

Concurrency Patterns：Golang中常见并发模式

Concurrency Patterns: Fan-in and Fan-out with Goroutines

Context and Goroutines: Managing Concurrency

Goroutines: Using Atomic Operations for Concurrency

concurrency in action, 2nd edition.pdf

java 外文参考文献_java英文参考文献

最新资源