動態

@poemyang

“一切皆文件”:揭秘LINUX I/O與虛擬內存的底層設計哲學

RPC框架如同構建服務大廈的神經網絡,承擔着海量服務間通信的重任。它優雅地屏蔽了底層網絡通信的複雜性,使開發者能聚焦於業務邏輯的創造。然而,在這份優雅之下,RPC框架的網絡模型設計卻是決定系統吞吐量、延遲和資源利用率的命脈,其核心在於在有限的硬件資源與無限的數據洪流之間,建立一座高效、動態的橋樑。 當每秒數以萬計的請求涌入時,如何在有限的硬件上實現近乎無損的調度?事件驅動機制如何以“四兩撥千

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

你的程序為何卡頓?從LINUX I/O三大模式尋找答案

I/O交互流程 在LINUX中,內核空間和用户空間都位於虛擬內存中。LINUX採用兩級保護機制:0級供內核使用,3級供用户程序使用。每個進程都有獨立的用户空間(0~3G),對其他進程不可見,而最高的1G虛擬內核空間則由所有進程和內核共享。 操作系統和驅動程序運行在內核空間,應用程序運行在用户空間。由於LINUX使用虛擬內存機制,兩者之間不能直接通過指針傳遞數據。用户空間必須通過系統調用

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

單線程如何撐起百萬連接?I/O多路複用:現代網絡架構的基石

I/O多路複用(I/O Multiplexing)是一種允許單個線程同時監視多個文件描述符的I/O模型。其核心價值在於,它將應用程序從低效的I/O等待中解放出來,實現了“一次等待,響應多個事件”的高效併發模式。 要理解其優勢,需要對比非阻塞I/O的侷限性。雖然非阻塞I/O能避免線程在數據未就緒時阻塞,但它要求應用程序通過循環不斷地主動輪詢所有文件描述符,這會造成大量的處理器空轉,浪費計算資源

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

從C10K到Reactor:事件驅動,如何重塑高併發服務器的網絡架構

事件驅動 事件驅動(Event Driven)是一種核心的編程範式,其根本特徵是控制反轉(Inversion of Control,IoC)。在這種模型中,程序的執行流不再由代碼的順序調用決定,而是由一系列異步發生的事件來驅動。應用程序的角色從主動輪詢或等待,轉變為被動地對事件做出響應,這構成了現代高性能系統的基礎。 一個完整的事件驅動架構由四個基本部分組成,它們協同工作,構成了高效的

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

職責分離的藝術:剖析主從Reactor模型如何實現極致的併發性能

Reactor單線程模型 在Reactor單線程模型中,所謂的“單線程”主要針對I/O操作而言,即所有的I/O操作(如accept()、read()、write()和connect())都在同一個線程上完成。然而,在當前的單線程Reactor模型中,不僅I/O操作由Reactor線程處理,非I/O的業務邏輯操作也在該線程上執行。這種設計可能導致I/O請求的響應被顯著延遲,因為耗時的業務邏輯會

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

“化零為整”的智慧:內存池如何繞過系統調用和GC,構建性能的護城河

內存池:精打細算的內存管家 在高性能系統(如網絡服務器)的極致優化中,當處理器和I/O的瓶頸被逐一攻克後,內存管理便成為決定系統延遲和吞吐量的最後一道,也是最關鍵的一道關隘。傳統的內存分配方式在這種場景下顯得力不從心,催生了通過內存池(Memory Pool)作為管理策略。 在C/C++或Java等語言中,依賴系統默認的內存分配機制(如malloc或new)在高併發場景下會引發一系列性

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

jemalloc思想的極致演繹:深度解構Netty內存池的精妙設計與實現

內存分配 Netty內存池的核心設計借鑑了jemalloc的設計思想。jemalloc是由Jason Evans在FreeBSD項目中實現的高性能內存分配器,其核心優勢在於通過細粒度內存塊劃分與多層級緩存機制,降低內存碎片率並優化高併發場景下的內存分配吞吐量。 Netty基於jemalloc的多Arena架構實現內存池化,每個運行實例維護固定數量的內存分配域(Arena),默認數量與處

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

為什麼Java/Python程序無需關心內存釋放?揭秘垃圾回收(GC)的核心概念

在Java的編程世界裏,開發者既無需也無法像C/C++那樣手動調用malloc/free來管理內存的分配與回收,這一核心任務完全由Java虛擬機在幕後自動完成。這種自動化設計極大地簡化了編碼,將開發者從繁瑣且極易出錯的內存管理中解放出來。然而,這種便利性的背後隱藏着一個經典且複雜的難題:一個動態運行的程序,其對象創建和消亡的模式千變萬化,Java虛擬機如何高效地追蹤這些對象的生命週期,在正確的時間

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

壓縮指針:64位系統下,Java虛擬機是如何“偷”回4字節內存的?

Java對象:在內存中的真面目 在Java中,通過new關鍵字創建一個Java類的實例對象時,該對象會通過碰撞指針方式存儲在內存的堆中,並被分配一個內存地址。在Java虛擬機中,一個Java對象由對象頭(Object Header)、實例數據(Instance Data)和對齊填充(Padding)三部分構成。 對象頭 對象頭由兩個字(計算機術語,表示計算機處理數據的最小單位)

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

誰生?誰死?從引用計數到可達性分析,洞悉GC的決策邏輯

引用計數與可達性分析:誰死了,誰還活着? 垃圾回收,顧名思義,便是將已經分配出去的,但卻不再使用的內存回收回來,以便能夠再次分配。在Java虛擬機的語境下,垃圾指的是死亡的對象所佔據的堆空間。這裏便涉及了一個關鍵的問題:如何辨別一個對象是存是亡? 引用計數 引用計數(Reference Counting)是一種古老的辨別方法,它的基本思想是給每個對象添加一個引用計數器,每當有一個引用指

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

為什麼我的應用會卡頓?垃圾回收中的STW難題與破解之道

垃圾回收算法:清除、壓縮、複製 可達性分析提供了一種有效的方式,來標記哪些對象死亡,哪些對象還存活。然而,確定哪些對象死亡可以被回收,只是垃圾回收的第一步, 這個過程通常被稱為標記(Mark)。接下來,需要一種方法來回收這些死亡對象佔用的內存,以便這些內存可以被重新使用。這就是垃圾回收算法的任務。 垃圾回收算法描述瞭如何有效地回收垃圾對象的內存,同時儘量減少對程序執行的影響。 清除

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

不止新生代與老年代:深入Java虛擬機堆內存佈局與TLAB、卡表等優化機制

Java虛擬機運行數據區域 在JDK 8及以上版本中,Java虛擬機運行時數據區域主要包括以下部分: 1)堆(Heap):這是Java虛擬機中最大的內存區域,所有線程共享,主要用於存放對象實例和數組。這也是垃圾回收的主要區域,因此也被稱作GC堆(Garbage Collection Heap)。 2)方法區(Method Area):在JDK 8之前,這被稱為永久代(PermGe

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

吞吐量、延遲、內存:深入理解垃圾回收的“三元悖論”

垃圾回收算法的評價標準:吞吐量、延遲、內存,孰輕孰重? 評估和選擇垃圾回收器時,不存在一體通用的最優解。不同的應用場景對性能的要求截然不同,因此需要通過一套標準化的指標來衡量垃圾回收算法的特性。通常,關注三個主要的、且相互制約的評價指標:吞吐量(Throughput)、最大暫停時間(Max Pause Time / Latency)以及堆使用效率(Heap Usage Efficiency)

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

告別漫長GC停頓:深入解析G1如何實現可預測的毫秒級響應

G1(Garbage-First)垃圾回收器是一款面向服務端應用、為大內存和多處理器系統設計的革命性垃圾回收器。G1的核心設計目標是在滿足高吞吐量的同時,建立一個“可預測的停頓時間模型”(Pause-Time Model),讓使用者可以明確指定在一個長度為M毫秒的時間片段內,消耗在垃圾回收上的時間大概率不超過N毫秒。這一特性是它與之前回收器(如CMS)最本質的區別。 在JDK 9發佈之後,G

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

內存泄漏 vs. 內存溢出:剖析Java虛擬機兩大內存絕症的病因與療法

內存泄漏和內存溢出是Java程序中最常見的兩類內存管理問題。它們都與內存息息相關,但本質、成因和解決方法截然不同。 內存泄漏 內存泄漏指的是程序在向系統申請內存後,由於設計缺陷或編碼錯誤,導致某些已經不再被使用的對象仍然被引用鏈持續持有,從而無法被垃圾回收器識別和回收。這些無用對象會像殭屍一樣永久地佔據內存空間。一次微小的泄漏可能無傷大雅,但如果泄漏持續發生並累積,會逐漸侵佔可用內存,導致垃

poemyang 頭像

@poemyang

昵稱 poemyang

@poemyang

萬丈高樓平地起:從“輸入-處理-輸出”第一性原理,看懂系統架構的演進

系統設計的複雜性,往往源於其需要應對的外部壓力。對於互聯網應用而言,用户規模的增長和流量的瞬時波動,是其必須面對的常態。一個未經深思熟慮的系統,在流量洪峯面前可能會變得遲緩甚至不可用,直接影響用户體驗與業務目標。 因此,構建一個能夠從容應對壓力的系統架構,便成為一項核心的工程命題。 本文將探討一種行之有效的設計哲學——分層抗壓。剖析其背後的三大技術支柱:緩存、消息中間件與數據庫,並闡述

poemyang 頭像

@poemyang

昵稱 poemyang

@wJiang

【實戰】深入淺出 Rust 併發:RwLock 與 Mutex 在 Tauri 項目中的實踐

引言 你是否遇到過 Rust 併發場景下的資源競爭、性能瓶頸? 當多個線程同時抓取網頁導致 IP 被封、多線程讀寫本地數據引發一致性問題時,如何優雅地實現線程安全? 本文結合開源項目 Saga Reader 的真實開發場景,深度解析 Arc/Mutex/RwLock 的實戰技巧,帶你從 “踩坑” 到 “優化”,掌握 Rust 併發編程的核心方法論,文末附項目地址,歡迎 star 交流!

wJiang 頭像

@wJiang

昵稱 姜 萌@cnblogs

@wJiang

【實戰】Rust與前端協同開發:基於Tauri的跨平台AI閲讀器實踐

一、背景與目標:為什麼做一個“非典型”的RSS閲讀器? 在信息爆炸的時代,RSS依然是高效獲取結構化內容的重要方式,但市面上主流閲讀器要麼功能冗餘(如集成社交屬性),要麼技術棧陳舊(依賴Electron導致內存佔用高、性能差)。我們希望打造一款簡約輕量、高效率、高性能、隱私安全的RSS閲讀器,核心需求包括: 智庫情報引擎:支持基於搜索引擎的信息抓取與RSS源訂閲。 由AI驅動的特色能力:自動

wJiang 頭像

@wJiang

昵稱 姜 萌@cnblogs

@czy

Rust中使用RocksDB索引進行高效範圍查詢的實踐指南

在當今海量數據處理場景下,高效的範圍查詢能力成為許多系統的關鍵需求。RocksDB作為一款高性能的嵌入式鍵值存儲引擎,其獨特的LSM樹結構和索引設計為範圍查詢提供了底層支持。本文將深入探討如何在Rust中利用RocksDB的特性來實現高效範圍查詢,從鍵的設計原則到迭代器的工程實踐,再到性能優化的實戰技巧。無論您是正在構建時序數據庫、構建搜索引擎,還是處理用户事件流,這些技術都能幫助您在保證數據一致

czy 頭像

@czy

昵稱 涵樹

@dx-2021

RabbitMQ簡單介紹及常見面試題

RabbitMQ簡介   MQP 即Advanced Message Queuing Protocol(高級消息隊列協議),是一個網絡協議,是應用協議的一個開發標準,為面向消息的中間件設計。基於此協議的客户端與消息中間件可傳遞消息,並不受客户端/中間件不同產品,不同的開發語言等條件的限制。2006年,AMQP規範發佈。類比HTTP。   2007年,Rabbit技術公司基於AMQP標準開發的

dx-2021 頭像

@dx-2021

昵稱 九尾妖狐·

@MikeZhang

使用RNNoise進行音頻降噪

操作系統:Debian 12.5_x64 Windows10_x64 rnnoise版本:0.2 gcc版本:12.2.0 python版本: 3.9.13 RNNoise是一個將傳統數字信號處理與深度學習相結合的開源實時音頻降噪庫,可在消耗極少計算資源的情況下實現毫秒級降噪,今天整理下這方面的筆記,希望對你有幫助。 該庫涉及算法的描述詳見論文(一種混合 DSP/深度學習方法的實時全頻帶語音增強

MikeZhang 頭像

@MikeZhang

昵稱 Mike_Zhang

@liuruian

[CSP 2025]遊記

CSP-J $T1$ 循環結構 $+$ 字符串,橙題,不説了肯定做出來了。 #includebits/stdc++.h using namespace std; #define int long long #define N 2000005 int top,a[N]; string s; signed main(){ cins,s=" "+s; for(int i=1;is.length

liuruian 頭像

@liuruian

昵稱 Ryan427