@併發

動態 列表
@jump_and_jump

聊聊併發控制鎖

對於企業應用來説,完全不涉及到併發的問題,基本是不可能的。因為對於一個應用中很多的事情都是同時進行的。併發可能發生在數據獲取,服務調用乃至於用户交互中。併發問題有兩個重要的解決方案,一個是隔離,另一個是不變性。 併發問題會發生在多個執行單元同時訪問同一資源的時候,此時,一個好的方法就是分好“蛋糕”,讓每一個執行單元都能訪問到各自的資源。好的併發設計就是:找到創建好隔離區的辦法,然後通過分析工作流讓

jump_and_jump 頭像

@jump_and_jump

昵稱 jump__jump

@jueqiangdeqianbi

如何用Postman模擬多用户併發?一步步教你實現

背景介紹 最近,我們發起了一個在線圖書管理系統的項目。我負責的一個關鍵模塊包括三個主要後台接口: 實現對books數據的檢索。 實施對likes數據的獲取。 通過collections端點訪問數據。 應對高流量的挑戰 在設計並部署接口時,我們不可避免地需要考慮關鍵的問題: 你製作的產品會不會面臨大量的訪問需求? 你的接口和服務器是否能夠處理如此高的用户訪問量? 歸根結底,問題是:

jueqiangdeqianbi 頭像

@jueqiangdeqianbi

昵稱 倔強的鉛筆

@dihuangwan

應用app的服務器如何增加高併發

增強服務器的高併發能力是現代網絡應用非常關鍵的需求。面對用户數量的不斷增長和數據量的膨脹,服務器必須能夠處理大量併發請求。以下是一些提高服務器高併發能力的常用方法和具體實施細節: 優化服務器和操作系統配置 服務器和操作系統的默認配置不一定能夠應對高併發場景。以下是一些優化措施的具體步驟和優勢: 調整最大文件描述符限制:默認情況下,操作系統可能對打開文件的數量有限制。通過修改 /etc/secur

dihuangwan 頭像

@dihuangwan

昵稱 咕嚕企業籤夢奇

@guaiguaidedoujiang_cmg5bc

Java故障案例分析第一期:父子任務使用不當線程池死鎖

引言 在Java多線程編程中,線程池是提高性能和資源利用率的常用工具。然而,當父子任務使用同一線程池時,可能導致潛在的死鎖問題。本文將深入分析一個實際案例,闡述為何這種設計可能引發死鎖,以及如何排查這類問題。 案例背景 考慮以下的偽代碼,展示了一個可能導致死鎖的場景: import java.util.concurrent.ExecutorService; import java.util.co

@gongzhengyang

Actor併發系統説明與使用

簡介 Actor模型是一種並行計算模型,提供了一種用於構建併發、分佈式系統的抽象方法 在Actor模型中,計算被表示為獨立的、輕量級的計算單元,稱為Actor,可以發送和接收消息並進行本地計算 作為一種通用的消息傳遞編程模型,被廣泛用於構建大規模可伸縮分佈式系統 核心思想是獨立維護隔離狀態,並基於消息傳遞實現異步通信 Actor模型組成 存儲:每個 Actor 持有一個郵箱(mailbox),

gongzhengyang 頭像

@gongzhengyang

昵稱 龔正陽

@debuginn

Phoenix框架 從0到1設計業務併發框架 小米商城產品站革新之路

前言 小米商城產品站之前由於歷史原因,存在着諸多問題與不便,隨着技術的快速變革,技術部中台化的建設,越來越不適用於現在快速迭代的業務需求,接下來我將以技術的視角講解我們遇到的痛點,以及解決這些痛點的思路,也就是 Phoenix 框架誕生的故事。 為啥要進行設計一個框架,其實是業務發展導向的結果,若是我們不進行設計,那麼我們會遇到如下一些問題: 在新的產品需求規劃下,無法承接大型項目,只能進行小

debuginn 頭像

@debuginn

昵稱 Meng小羽

@debuginn

Phoenix框架 從0到1設計業務併發框架 怎麼組織設計一個框架

上篇文章主要講了設計 Phoenix 框架前的遇到的問題和設計框架的思路 《 Phoenix 框架 從0到1設計業務併發框架 小米商城產品站革新之路》,本篇文章主要講一下如何設計框架的。 不死鳥併發框架,是自動構建有向圖按照深度進行構建併發組並進行併發調用結果的框架。 產品站業務靜態接口與動態接口都需要調用大量的後台服務進行獲取數據進行業務編排,而各個併發調用之間又相互存在依賴,採用併發組設計拆解

debuginn 頭像

@debuginn

昵稱 Meng小羽

@debuginn

Phoenix框架 從0到1設計業務併發框架 併發線程池的核心設計

背景 從 0 到 1 設計業務併發框架系列: Phoenix 框架 小米商城產品站革新之路 Phoenix 框架 怎麼組織設計一個框架 前兩篇文章已經講述了我設計框架的背景以及抽象設計的細節,今天講一下併發框架最為關鍵的併發線程池的核心設計,主要講一下在設計線程池劃分遇到的問題以及最終我採用了哪種方式實現的。 將存在依賴關係的 Task 進行劃分分組後,依次執行分組就可以拿到所有想要的結

debuginn 頭像

@debuginn

昵稱 Meng小羽

@debuginn

Phoenix框架 從0到1設計業務併發框架 自動構建有向無循環圖設計

從 0 到 1 設計業務併發框架系列: Phoenix 框架 小米商城產品站革新之路 Phoenix 框架 怎麼組織設計一個框架 Phoenix 框架 併發線程池的核心設計 Phoenix 自動構建有向無環圖的業務併發框架,核心就在於不需要開發人員關心調用分層和依賴互斥的排序問題,通過算法進行自動構建、收集 Task 任務、檢測環或者依賴,最後打印併發組分層信息。 本篇文章就講解下如何構

debuginn 頭像

@debuginn

昵稱 Meng小羽

@onlythinking

學習Go語言併發編程

關於併發 Go 語言的創始人Rob Pike 曾説過:並行關乎執行,併發關乎結構。他認為: • 併發是一種程序設計方法:將一個程序分解成多個小片段,每個小片段獨立執行;併發程序的小片段之間可以通過通信相互協作。 • 並行是有關執行的,它表示同時進行一些計算任務。 程序小片段之間通訊不同語言實現不同,比如:傳統語言Java使用共享內存方式達到線程之間通訊,而Go語言channel來進行通

onlythinking 頭像

@onlythinking

昵稱 編程碼農

@renzhendezicai

Android面試題之Kotlin協程併發問題和互斥鎖

本文首發於公眾號“AntDream”,歡迎微信搜索“AntDream”或掃描文章底部二維碼關注,和我一起每天進步一點點 Kotlin 語言提供了多種機制來處理併發和同步,其中包括高層次和低層次的工具。對於常規的併發任務,可以利用 Kotlin 協程提供的結構化併發方式。而對於需要更低層次的鎖定機制,可以使用 Mutex 來實現對共享資源的線程安全訪問。 Kotlin 協程與併發(Coroutine

renzhendezicai 頭像

@renzhendezicai

昵稱 認真的紫菜

@bug1412

Workflow通用併發控制組件:ResourcePool資源池

開源項目Workflow是C++異步調度的高性能框架,廣泛用於高吞吐低延遲的網絡服務器、並行計算和組裝複雜網絡請求的客户端等領域。在異步調度的編程範式下,想要實現併發控制是非常困難的,因為一旦無法做到無阻塞的調度,那麼框架性能就會大打折扣。 線上非常常見的場景是:異步服務器需要限制用户的併發,從而保護有限的後端資源比如GPU計算,並在超載時可以立刻拒絕用户或者實施排隊等待的處理策略。 一個好的併發

bug1412 頭像

@bug1412

昵稱 1412

@hnclou

華納雲:服務器併發量測試和優化

服務器併發量是指在同一時間內能夠同時處理的請求數量。併發量是衡量服務器性能的重要指標之一,影響併發量的因素包括CPU、內存、網絡帶寬、磁盤IO和應用程序的設計與優化。以下是一些常見的方法和工具來測試、監控和優化服務器的併發量。 測試服務器併發量 選擇測試工具常用的壓力測試工具包括: Apache JMeter:一個功能強大的負載測試工具。 Siege:一個簡單的HTTP負載測試工具。

hnclou 頭像

@hnclou

昵稱 用户bPddcxP

@jianghushinian

Go 併發控制:sync.WaitGroup 詳解

首發地址:https://mp.weixin.qq.com/s/-FtDLcHW39vgvqSMUVM-yw 前段時間我在《Go 併發控制:errgroup 詳解》一文中講解了 errgroup 的用法和源碼,通過源碼我們知道 errgroup 內部是使用 sync.WaitGroup 實現的,那麼本文就更進一步,來探索下 sync.WaitGroup 源碼是如何實現的。 使用示例 sync.Wa

jianghushinian 頭像

@jianghushinian

昵稱 江湖十年

@jianghushinian

Go 併發控制:sync.Map 詳解

我們知道,Go 中的 map 類型是非併發安全的,所以 Go 就在 sync 包中提供了 map 的併發原語 sync.Map,允許併發操作,本文就帶大家詳細解讀下 sync.Map 的原理。 使用示例 sync.Map 提供了基礎類型 map 的常用功能,使用示例如下: package main import ( "fmt" "sync" ) func main() {

jianghushinian 頭像

@jianghushinian

昵稱 江湖十年

@jianghushinian

Go 併發編程:如何實現一個併發安全的 map

上週發佈的文章「Go 併發控制:sync.Map 詳解」有讀者反饋説我寫的太難了,上來就挑戰源碼,對新手不夠友好。所以這篇文章算作補充,從入門到進階的順序講解一下在 Go 中如何自己實現一個併發安全的 map。 內置 map 首先,我們來測試一下 Go 語言內置 map 併發安全性,示例如下: https://github.com/jianghushinian/blog-go-example/tr

jianghushinian 頭像

@jianghushinian

昵稱 江湖十年

@jianghushinian

在 Go 中如何使用分佈式鎖解決併發問題?

在分佈式系統中,協調多個服務實例之間的共享資源訪問是一個經典的挑戰。傳統的單機鎖(如 sync.Mutex)無法實現跨進程工作,此時就需要用到分佈式鎖了。本文將介紹 Go 語言生態中基於 Redis 實現的分佈式鎖庫 redsync,並探討其使用方法和實現原理。 分佈式鎖 首先我們來探討下為什麼需要分佈式鎖?當我們編寫的程序出現資源競爭的時候,就需要使用互斥鎖來保證併發安全。而我們的服務很有可能不

jianghushinian 頭像

@jianghushinian

昵稱 江湖十年

@chen_67f9ccbe6f07b

Java併發問題排查實戰手冊:死鎖與活鎖診斷與解決全流程

一、引言 併發編程就像是在廚房裏同時炒 10 道菜 - 看似效率提高了,但一不小心就會手忙腳亂。作為 Java 後端開發,我們經常為併發問題頭疼不已:生產環境突然卡死,線程 CPU 使用率飆升卻沒有業務進展,各種監控工具報警...而當你想復現問題時,它又像幽靈一樣"按鬧分配",讓人抓狂。 併發 BUG 難以排查的原因主要有三: 不確定性:同樣的代碼,運行 10 次可能只出現 1 次問題 複雜

chen_67f9ccbe6f07b 頭像

@chen_67f9ccbe6f07b

昵稱 異常君

@chen_67f9ccbe6f07b

深入剖析 Java 併發容器:解鎖 ConcurrentHashMap 底層原理與高性能實戰應用

1. 併發容器的歷史 大家好,今天我們來聊一個 Java 多線程開發中繞不開的核心話題:併發容器。可能你已經發現,當我們在多線程環境中使用 HashMap、ArrayList 這些集合類時,經常會遇到ConcurrentModificationException或數據不一致的問題,這就是因為這些普通集合類不是線程安全的。 JDK 提供的傳統解決方案是Collections.synchronized

chen_67f9ccbe6f07b 頭像

@chen_67f9ccbe6f07b

昵稱 異常君

@user_zsxbv7bi

我所理解的 Go 的 CSP 併發控制機制

你一定聽説過 Go 語言所倡導的這個核心併發原則:“不要通過共享內存來通信,而要通過通信來共享內存 (Don't communicate by sharing memory; instead, share memory by communicating)”。這一理念深刻影響了 Go 的併發設計。 本文將具體討論 Go 中的 併發控制機制 (concurrency control mechanism

user_zsxbv7bi 頭像

@user_zsxbv7bi

昵稱 user_zsXbv7Bi

@niandou

腦抽研究生Go併發-1-基本併發原語-下-Cond、Once、Map、Pool、Context

Once 單例對象:在整個應用程序的生命週期中,只有一個實例存在,並提供一個全局統一的訪問點來獲取這個唯一的實例 應用場景:數據庫連接池,全局配置管理器,日誌記錄器 (Logger) Once 是在 Go 語言中實現線程安全的單例模式的完美且最地道的工具 使用 Once 可能出現的 2 種錯誤 第一種錯誤:死鎖 ​ once.Do()中再次調用once.Do() 第二種錯誤

niandou 頭像

@niandou

昵稱 粘豆煮包

@finally_m

金融系統中Java如何處理大量的交易和請求

金融服務行業需要處理大量的交易和請求,Java的多線程能力可以有效地管理這些併發操作,確保系統的響應性和效率。 在金融服務行業中,例如一個股票交易平台,它需要處理大量的買入和賣出請求,交易邏輯會涉及數據庫交互、錯誤處理和事務管理等方面的複雜性。這就是一個 Java 多線程能力的點型應用了,V 哥從項目中剝離了這個案例,分享給你參考。 1. 定義交易請求和響應 在金融服務行業中,定義清晰的交易請求和

finally_m 頭像

@finally_m

昵稱 威哥愛編程