目录
问题内容
解决方法
问题
可靠的设计
manager.go
main.go
manager_test.go
首页 后端开发 Golang 这个Golang程序中的同步问题

这个Golang程序中的同步问题

Feb 10, 2024 am 09:06 AM
同步机制

这个Golang程序中的同步问题

php小编苹果今天为大家介绍一个有趣的话题——"这个Golang程序中的同步问题"。在编写并发程序时,我们经常会遇到同步问题,即多个线程之间的竞争和协调。Golang作为一门并发编程语言,提供了丰富的同步机制和工具,但也存在一些常见的同步问题需要我们注意和解决。本文将详细探讨这些问题,并给出相应的解决方案,帮助大家更好地理解和应对Golang中的同步挑战。让我们一起来探索吧!

问题内容

我正在尝试创建一个充当代理服务器并可以动态切换到新端点的程序。但我遇到一个问题,在调用 switchovertonewendpoint() 后,仍然有一些代理对象连接到原始端点 8.8.8.8 ,应该将其关闭。

package main

import (
    "net"
    "sync"
    "sync/atomic"
    "time"
)

type proxy struct {
    id       int32
    from, to *net.tcpconn
}

var switchover int32 = 0

func setswitchover() {
    atomic.storeint32((*int32)(&switchover), 1)
}

func switchoverenabled() bool {
    return atomic.loadint32((*int32)(&switchover)) == 1
}

var proxies map[int32]*proxy = make(map[int32]*proxy, 0)
var proxyseq int32 = 0
var mu sync.rwmutex

func addproxy(from *net.tcpconn) {
    mu.lock()
    proxyseq += 1
    proxy := &proxy{id: proxyseq, from: from}
    proxies[proxyseq] = proxy
    mu.unlock()

    var toaddr string
    if switchoverenabled() {
        toaddr = "1.1.1.1"
    } else {
        toaddr = "8.8.8.8"
    }
    tcpaddr, _ := net.resolvetcpaddr("tcp4", toaddr)
    toconn, err := net.dialtcp("tcp", nil, tcpaddr)
    if err != nil {
        panic(err)
    }
    proxy.to = toconn
}

func switchovertonewendpoint() {
    mu.rlock()
    closedproxies := proxies
    mu.runlock()

    setswitchover()
    for _, proxy := range closedproxies {
        proxy.from.close()
        proxy.to.close()
        mu.lock()
        delete(proxies, proxy.id)
        mu.unlock()
    }
}

func main() {
    tcpaddr, _ := net.resolvetcpaddr("tcp4", "0.0.0.0:5432")
    ln, _ := net.listentcp("tcp", tcpaddr)
    go func() {
        time.sleep(time.second * 30)
        switchovertonewendpoint()
    }()
    for {
        clientconn, err := ln.accepttcp()
        if err != nil {
            panic(err)
        }
        go addproxy(clientconn)
    }
}
登录后复制

想了一会儿,我猜问题出在

mu.rlock()
    closedproxies := proxies
    mu.runlock()
登录后复制

但我不确定这是否是根本原因,以及是否可以通过将其替换为以下内容来修复它:

closedProxies := make([]*Proxy, 0)
    mu.RLock()
    for _, proxy := range proxies {
        closedProxies = append(closedProxies, proxy)
    }
    mu.RUnlock()
登录后复制

由于该案例很难重现,所以有专业人士可以提供想法或提示吗?欢迎任何评论。提前致谢。

解决方法

问题

改变是必要的。在最初的实现中, latedproxies 持有相同的映射。请参阅此演示:

package main

import "fmt"

func main() {
    proxies := make(map[int]int, 0)
    for i := 0; i < 10; i++ {
        proxies[i] = i
    }

    closeproxies := proxies

    proxies[10] = 10
    proxies[11] = 11

    for k := range closeproxies {
        delete(proxies, k)
    }

    fmt.printf("items left: %d\n", len(proxies))
    // output:
    //   items left: 0
}
登录后复制

但这不是根本原因。可以在复制 closeproxies 之后但在调用 setswitchover 之前添加新代理。在这种情况下,新代理连接到旧地址,但不在 closeproxies 中。我认为这是根本原因。

还有一个问题。在设置 to 字段之前,将向 proxies 添加新代理。程序可能希望在设置 to 字段之前关闭此代理,从而导致恐慌。

可靠的设计

这个想法是将所有端点放入一个切片中,并让每个端点管理自己的代理列表。所以我们只需要跟踪当前端点的索引。当我们想要切换到另一个端点时,我们只需要更改索引,并告诉过时的端点清除其代理。剩下的唯一复杂的事情是确保过时的端点可以清除其所有代理。请参阅下面的实现:

manager.go

这就是这个想法的实现。

package main

import (
    "sync"
)

// conn is abstraction of a connection to make manager easy to test.
type conn interface {
    close() error
}

// dialer is abstraction of a dialer to make manager easy to test.
type dialer interface {
    dial(addr string) (conn, error)
}

type manager struct {
    // mucurrent protects the "current" member.
    mucurrent sync.rwmutex
    current   int // when current is -1, the manager is shuted down.
    endpoints []*endpoint

    // mu protects the whole switch action.
    mu sync.mutex
}

func newmanager(dialer dialer, addresses ...string) *manager {
    if len(addresses) < 2 {
        panic("a manger should handle at least 2 addresses")
    }

    endpoints := make([]*endpoint, len(addresses))
    for i, addr := range addresses {
        endpoints[i] = &endpoint{
            address: addr,
            dialer:  dialer,
        }
    }
    return &manager{
        endpoints: endpoints,
    }
}

func (m *manager) addproxy(from conn) {
    // 1. addproxy will wait when the write lock of m.mucurrent is taken.
    // once the write lock is released, addproxy will connect to the new endpoint.
    // switch only holds the write lock for a short time, and switch is called
    // not so frequently, so addproxy won't wait too much.
    // 2. switch will wait if there is any addproxy holding the read lock of
    // m.mucurrent. that means switch waits longer. the advantage is that when
    // e.clear is called in switch, all addproxy requests to the old endpoint
    // are done. so it's safe to call e.clear then.
    m.mucurrent.rlock()
    defer m.mucurrent.runlock()

    current := m.current

    // do not accept any new connection when m has been shutdown.
    if current == -1 {
        from.close()
        return
    }

    m.endpoints[current].addproxy(from)
}

func (m *manager) switch() {
    // in a real world, switch is called not so frequently.
    // so it's ok to add a lock here.
    // and it's necessary to make sure the old endpoint is cleared and ready
    // for use in the future.
    m.mu.lock()
    defer m.mu.unlock()

    // take the write lock of m.mucurrent.
    // it waits for all the addproxy requests holding the read lock to finish.
    m.mucurrent.lock()
    old := m.current

    // do nothing when m has been shutdown.
    if old == -1 {
        m.mucurrent.unlock()
        return
    }
    next := old + 1
    if next >= len(m.endpoints) {
        next = 0
    }
    m.current = next
    m.mucurrent.unlock()

    // when it reaches here, all addproxy requests to the old endpoint are done.
    // and it's safe to call e.clear now.
    m.endpoints[old].clear()
}

func (m *manager) shutdown() {
    m.mu.lock()
    defer m.mu.unlock()

    m.mucurrent.lock()
    current := m.current
    m.current = -1
    m.mucurrent.unlock()

    m.endpoints[current].clear()
}

type proxy struct {
    from, to conn
}

type endpoint struct {
    address string
    dialer  dialer

    mu      sync.mutex
    proxies []*proxy
}

func (e *endpoint) clear() {
    for _, p := range e.proxies {
        p.from.close()
        p.to.close()
    }

    // assign a new slice to e.proxies, and the gc will collect the old one.
    e.proxies = []*proxy{}
}

func (e *endpoint) addproxy(from conn) {
    toconn, err := e.dialer.dial(e.address)
    if err != nil {
        // close the from connection so that the client will reconnect?
        from.close()
        return
    }

    e.mu.lock()
    defer e.mu.unlock()
    e.proxies = append(e.proxies, &proxy{from: from, to: toconn})
}
登录后复制

main.go

这个演示展示了如何使用之前实现的manager类型:

package main

import (
    "net"
    "time"
)

type realdialer struct{}

func (d realdialer) dial(addr string) (conn, error) {
    tcpaddr, err := net.resolvetcpaddr("tcp4", addr)
    if err != nil {
        return nil, err
    }
    return net.dialtcp("tcp", nil, tcpaddr)
}

func main() {
    manager := newmanager(realdialer{}, "1.1.1.1", "8.8.8.8")

    tcpaddr, _ := net.resolvetcpaddr("tcp4", "0.0.0.0:5432")
    ln, _ := net.listentcp("tcp", tcpaddr)

    go func() {
        for range time.tick(30 * time.second) {
            manager.switch()
        }
    }()
    for {
        clientconn, err := ln.accepttcp()
        if err != nil {
            panic(err)
        }
        go manager.addproxy(clientconn)
    }
}
登录后复制

manager_test.go

使用以下命令运行测试:go test ./... -race -count 10

package main

import (
    "errors"
    "math/rand"
    "sync"
    "sync/atomic"
    "testing"
    "time"

    "github.com/google/uuid"
)

func TestManager(t *testing.T) {
    addresses := []string{"1.1.1.1", "8.8.8.8"}
    dialer := newDialer(addresses...)
    manager := NewManager(dialer, addresses...)

    ch := make(chan int, 1)

    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        for range ch {
            manager.Switch()
        }
        wg.Done()
    }()

    count := 1000
    total := count * 10

    wg.Add(total)

    fromConn := &fakeFromConn{}
    for i := 0; i < total; i++ {
        if i%count == count-1 {
            ch <- 0
        }
        go func() {
            manager.AddProxy(fromConn)
            wg.Done()
        }()
    }
    close(ch)

    wg.Wait()

    manager.Shutdown()

    for _, s := range dialer.servers {
        left := len(s.conns)
        if left != 0 {
            t.Errorf("server %s, unexpected connections left: %d", s.addr, left)
        }
    }

    closedCount := fromConn.closedCount.Load()

    if closedCount != int32(total) {
        t.Errorf("want closed count: %d, got: %d", total, closedCount)
    }
}

type fakeFromConn struct {
    closedCount atomic.Int32
}

func (c *fakeFromConn) Close() error {
    c.closedCount.Add(1)

    return nil
}

type fakeToConn struct {
    id     uuid.UUID
    server *fakeServer
}

func (c *fakeToConn) Close() error {
    if c.id == uuid.Nil {
        return nil
    }

    c.server.removeConn(c.id)

    return nil
}

type fakeServer struct {
    addr  string
    mu    sync.Mutex
    conns map[uuid.UUID]bool
}

func (s *fakeServer) addConn() (uuid.UUID, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    id, err := uuid.NewRandom()
    if err == nil {
        s.conns[id] = true
    }
    return id, err
}

func (s *fakeServer) removeConn(id uuid.UUID) {
    s.mu.Lock()
    defer s.mu.Unlock()

    delete(s.conns, id)
}

type fakeDialer struct {
    servers map[string]*fakeServer
}

func newDialer(addresses ...string) *fakeDialer {
    servers := make(map[string]*fakeServer)
    for _, addr := range addresses {
        servers[addr] = &fakeServer{
            addr:  addr,
            conns: make(map[uuid.UUID]bool),
        }
    }
    return &fakeDialer{
        servers: servers,
    }
}

func (d *fakeDialer) Dial(addr string) (Conn, error) {
    n := rand.Intn(100)
    if n == 0 {
        return nil, errors.New("fake network error")
    }
    // Simulate network latency.
    time.Sleep(time.Duration(n) * time.Millisecond)

    s := d.servers[addr]
    id, err := s.addConn()
    if err != nil {
        return nil, err
    }
    conn := &fakeToConn{
        id:     id,
        server: s,
    }
    return conn, nil
}
登录后复制

以上是这个Golang程序中的同步问题的详细内容。更多信息请关注PHP中文网其他相关文章!

本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn

热AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover

AI Clothes Remover

用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool

Undress AI Tool

免费脱衣服图片

Clothoff.io

Clothoff.io

AI脱衣机

AI Hentai Generator

AI Hentai Generator

免费生成ai无尽的。

热门文章

R.E.P.O.能量晶体解释及其做什么(黄色晶体)
4 周前 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O.最佳图形设置
4 周前 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O.如果您听不到任何人,如何修复音频
4 周前 By 尊渡假赌尊渡假赌尊渡假赌
WWE 2K25:如何解锁Myrise中的所有内容
1 个月前 By 尊渡假赌尊渡假赌尊渡假赌

热工具

记事本++7.3.1

记事本++7.3.1

好用且免费的代码编辑器

SublimeText3汉化版

SublimeText3汉化版

中文版,非常好用

禅工作室 13.0.1

禅工作室 13.0.1

功能强大的PHP集成开发环境

Dreamweaver CS6

Dreamweaver CS6

视觉化网页开发工具

SublimeText3 Mac版

SublimeText3 Mac版

神级代码编辑软件(SublimeText3)

golang函数与goroutine的父子关系 golang函数与goroutine的父子关系 Apr 25, 2024 pm 12:57 PM

Go中函数与goroutine存在父子关系,父goroutine创建子goroutine,子goroutine可以访问父goroutine的变量但不反之。创建子goroutine使用go关键字,子goroutine通过匿名函数或命名的函数执行。父goroutine可以通过sync.WaitGroup等待子goroutine完成,以确保在所有子goroutine完成之前不会退出程序。

golang函数与goroutine的优缺点比较 golang函数与goroutine的优缺点比较 Apr 25, 2024 pm 12:30 PM

函数用于顺序执行任务,简单易用,但存在阻塞和资源受限问题。Goroutine是并发执行任务的轻量级线程,具有高并发性、可伸缩性和事件处理能力,但使用复杂,开销较大,且难以调试。在实战中,Goroutine在并发任务时通常比函数具有更好的性能。

PHP 函数在多线程环境中的行为如何? PHP 函数在多线程环境中的行为如何? Apr 16, 2024 am 10:48 AM

在多线程环境中,PHP函数的行为取决于其类型:普通函数:线程安全,可并发执行。修改全局变量的函数:不安全,需使用同步机制。文件操作函数:不安全,需使用同步机制协调访问。数据库操作函数:不安全,需使用数据库系统机制防止冲突。

C++并发编程:如何处理线程间通信? C++并发编程:如何处理线程间通信? May 04, 2024 pm 12:45 PM

C++中线程间通信的方法包括:共享内存、同步机制(互斥锁、条件变量)、管道、消息队列。例如,使用互斥锁保护共享计数器:声明互斥锁(m)、共享变量(counter);每个线程通过加锁(lock_guard)更新计数器;确保一次只有一个线程更新计数器,防止竞争条件。

C++ 中有哪些并发编程框架和库?它们各自的优点和局限性是什么? C++ 中有哪些并发编程框架和库?它们各自的优点和局限性是什么? May 07, 2024 pm 02:06 PM

C++并发编程框架具有以下选项:轻量级线程(std::thread);线程安全的Boost并发容器和算法;用于共享内存多处理器的OpenMP;高性能ThreadBuildingBlocks(TBB);跨平台C++并发互操作库(cpp-Concur)。

volatile在java中的用法 volatile在java中的用法 May 01, 2024 pm 06:42 PM

volatile关键字用于修饰变量,确保所有线程都能看到变量的最新值并保证对变量的修改是一个不可中断的操作。主要应用场景包括多线程共享变量、内存屏障和并发编程。但需要注意的是,volatile不能保证线程安全,可能会降低性能,只应在绝对必要时使用。

并发编程中 C++ 函数的锁与同步机制? 并发编程中 C++ 函数的锁与同步机制? Apr 27, 2024 am 11:21 AM

C++并发编程中函数锁和同步机制用于管理多线程环境中数据的并发访问,防止数据竞争。主要机制包括:互斥量(Mutex):低级同步原语,确保一次只有一个线程访问临界区。条件变量(ConditionVariable):允许线程等待条件满足,提供线程间通信。原子操作:单指令操作,确保变量或数据的单线程更新,防止冲突。

程序性能优化有哪些常见的方法? 程序性能优化有哪些常见的方法? May 09, 2024 am 09:57 AM

程序性能优化方法包括:算法优化:选择时间复杂度更低的算法,减少循环和条件语句。数据结构选择:根据数据访问模式选择合适的数据结构,如查找树和哈希表。内存优化:避免创建不必要对象,释放不再使用的内存,使用内存池技术。线程优化:识别可并行化任务,优化线程同步机制。数据库优化:创建索引加快数据检索,优化查询语句,使用缓存或NoSQL数据库提升性能。

See all articles