Go语言并发实战：工具与技术解析

5星 · 超过95%的资源需积分: 9 169 浏览量更新于2024-07-19 1 收藏 4.31MB PDF 举报

"Concurrency in Go: Tools and Techniques for Developers" 是一本专注于Go语言并发技术的书籍，作者Katherine Cox-Buday。这本书对于了解和掌握Go（Golang）并发编程的开发者来说是一个宝贵的资源，尤其在Go语言相关资料相对较少的情况下。并发编程是Go语言的核心特性之一，它使得Go在处理多任务时能够高效地利用系统资源，提高程序性能。书中可能涵盖了以下几个主要知识点： 1. **Goroutines和Channels** - Goroutines是Go语言轻量级的线程实现，它们比传统的线程更高效，创建和销毁的成本更低。Channels则是Go语言中用于goroutine间通信的主要机制，通过它们可以实现数据的安全共享，避免竞态条件。 2. **互斥锁(Mutexes)** - 在Go中，互斥锁用于保护共享资源，确保同一时间只有一个goroutine可以访问。书里可能会详细讲解如何正确使用sync包中的Mutex，以及避免死锁的情况。 3. **选择器(Selectors)** - 选择器允许一个goroutine等待多个channels的操作，根据channel准备好进行通信的状态，选择其中一个进行处理，是Go并发模型的重要组成部分。 4. **缓冲区与无缓冲区Channels** - 缓冲区Channels可以存储一定数量的数据，无缓冲区Channels则要求发送和接收必须同步，这有助于实现同步和流量控制。 5. **WaitGroup** - sync.WaitGroup是一个同步原语，用于等待一组goroutines完成执行。在并发任务的启动和结束管理中起到关键作用。 6. **Context** - Context包提供了上下文对象，用于传递取消信号、截止时间和配置信息，常用于长运行的goroutines或网络请求，以支持取消操作。 7. **并行性和并发性的概念** - 书中会深入讨论这两个概念的区别，以及在Go中如何实现并发编程，以提高软件性能。 8. **错误处理和异常** - 并发环境中，错误处理尤为重要。书可能讲解了如何优雅地处理并发中的错误，以及如何使用panic和recover机制。 9. **实战案例** - 可能包含多种实际应用场景，如网络服务器、数据库连接池、并行计算等，帮助读者理解并发技术的实际应用。 10. **最佳实践和陷阱** - 提供了如何避免并发编程中常见的问题，比如数据竞争、死锁和资源泄漏等，以提升代码质量和可靠性。这本书对于想要深入理解和应用Go语言并发特性的开发者来说，是一本不可多得的指南，不仅介绍了基础概念和技术，还可能涵盖了高级主题和最佳实践。通过学习，读者将能够更好地利用Go的并发能力，编写出高效、可靠的并发程序。

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

剩余237页未读，继续阅读

jacyo

粉丝: 1
资源: 6

Go语言并发实战：工具与技术解析

Concurrency in Go Tools and Techniques for Developers epub

Concurrency in Go: Tools and Techniques for Developers

Oreilly.Concurrency.in.Go.Tools.and.Techniques.for.Developers

describe the difference between parallelism and concurrency in embedded system

default_concurrency_level

c++ concurrency in action 2nd

concurrency mysql

CORE_PEER_LIMITS_CONCURRENCY_GATEWAYSERVICE

c++ concurrency in action epub

concurrency in action, 2nd edition.pdf

最新资源