貢獻者33
粉絲0
一、StarRocks 產品簡介 StarRocks 是一款高性能分析型數據庫，專為海量數據的實時分析而設計。作為新一代湖倉（Lakehouse）加速引擎，StarRocks 融合了 MPP 架構和列式存儲引擎的優勢，能夠支持億級數據秒級查詢響應。 核心特性： 全面的數據模型：支持明細模型、主鍵模型和聚合模型，滿足多樣化業務場景 實時數據分析：提供高效的數據導入與更新能力，支持實時數據處理
昵稱 鏡舟科技
前言 大家好！今天我要和你們分享一個在 Java 開發中常見但又容易被忽視的問題：Caffeine 緩存引起的內存泄漏。作為目前 Java 生態中性能最強的本地緩存庫，Caffeine 被廣泛應用於各種項目中。但是，如果使用不當，它可能會變成你係統中的"內存黑洞"。 在這篇文章中，我會用通俗易懂的語言，結合實際案例，深入分析 Caffeine 緩存可能導致的內存泄漏問題，並提供針對性的解決方案。無
昵稱 異常君
還記得第一次遇到這種情況嗎？你寫了一段比較兩個 Integer 對象的代碼，有時候==返回 true，有時候卻返回 false，明明看起來是相同的值。這並非 Java 的"陷阱"，而是 Integer 緩存池在默默工作。我第一次遇到這個問題時，足足調試了半小時才恍然大悟。今天，我們就來深入瞭解這個經常被忽視卻又至關重要的 Java 性能優化機制。 什麼是 Integer 緩存池？ Integer
昵稱 異常君
[toc] 引言 持久化層和緩存層的一致性問題也通常被稱為「雙寫一致性問題」，“雙寫”意為數據既在數據庫中保存一份，也在緩存中保存一份。對於一致性來説，包含強一致性和弱一致性，強一致性保證寫入後立即可以讀取，弱一致性則不保證立即可以讀取寫入後的值，而是儘可能的保證在經過一定時間後可以讀取到，在弱一致性中應用最為廣泛的模型則是最終一致性模型，即保證在一定時間之後寫入和讀取達到一致的狀態。 我們一般會
昵稱 牛肉燒烤屋
序 本文主要研究一下JetCache的CachePenetrationProtect CachePenetrationProtect com/alicp/jetcache/anno/CachePenetrationProtect.java @Documented @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD, Ele
昵稱 codecraft
序 本文主要研究一下JetCache的緩存構建 invokeWithCached com/alicp/jetcache/anno/method/CacheHandler.java private static Object invokeWithCached(CacheInvokeContext context) throws Throwable {
昵稱 codecraft
序 本文主要研究一下redisson的lockWatchdogTimeout lockWatchdogTimeout redisson/src/main/java/org/redisson/config/Config.java private long lockWatchdogTimeout = 30 * 1000; /** * This parameter is o
昵稱 codecraft
序 本文主要研究一下redisson的RLock的unlock RLock org/redisson/api/RLock.java /** * Redis based implementation of {@link java.util.concurrent.locks.Lock} * Implements re-entrant lock. * * @author Nikita Koksh
昵稱 codecraft
一、熱點數據預加載 // 使用Redis HyperLogLog統計訪問頻率 public void recordAccess(Long productId) { String key = "access:product:" + productId; redis.pfadd(key, UUID.randomUUID().toString()); redis.
昵稱 粗眉毛的硬盤
這篇文章開始小亦平台會持續給大家科普一些運維過程中常見的問題解決案例，運維朋友們可以在常見問題及解決方案專欄查看更多案例。 問題概述 2024年3月1日，某客户反饋Redis隊列堆積導致應用卡頓。系統環境如下： 操作系統：Linux Redis版本：4.0.10 架構：Sentinel 經排查，系統因內存不足觸發Swap交換分區，嚴重拖慢Redis性能。 問題分析 分
昵稱 小亦智能運維
在分佈式系統和高併發應用中，緩存與數據庫的一致性是一個核心挑戰。關於"先刪除緩存還是先更新數據庫"的問題，業界有深入研究和多種實踐方案。以下是綜合分析： 兩種策略對比 1. 先刪除緩存，再更新數據庫（Cache-Aside模式） 流程 刪除緩衝中的數據 更新數據庫中的新數據 優點 實現簡單直觀 確保後續讀取能獲取最新數據（因為緩存已刪除） 缺點 在併發讀寫時可能導致
昵稱 ChiefHela
Release Notes 1、【升級】項目升級JDK17； 2、【升級】項目部分依賴升級，如caffeine，適配JDK17； 3、【優化】L1緩存廣播發布/訂閲斷連重連優化(ISSUE-32)； 4、【重構】合併PR-28，重構 getCache 方法並優化性能； 5、【優化】合併PR-35，引入單元測試框架，重寫單元測試方法； 6、【升級】多個依賴升級最新版本，如jedis、c
昵稱 xuxueli
引言 在為應用程序添加緩存時，首先需要考慮緩存策略。緩存策略決定了從緩存和底層存儲（如數據庫或服務）進行讀寫操作的方式。 從高層次來看，你需要決定在發生緩存未命中（cache miss）時，緩存是被動還是主動的。也就是説，當應用程序從緩存中查找一個值但該值不存在或已過期時，緩存策略會決定是由應用程序還是緩存本身從底層存儲中獲取數據。不同的緩存策略在延遲和複雜性之間存在不同的權衡，下面我們將逐一探討
昵稱 葡萄城技術團隊
【高心星出品】 Repeat組件的使用 概念 Repeat基於數組類型數據來進行循環渲染，一般與容器組件配合使用。 Repeat根據容器組件的有效加載範圍（屏幕可視區域+預加載區域）加載子組件。當容器滑動/數組改變時，Repeat會根據父容器組件的佈局過程重新計算有效加載範圍，並管理列表子組件節點的創建與銷燬。 Repeat必須在滾動類容器組件內使用，僅有List、ListItemGro
昵稱 高心星
一、引 言 為什麼進行源碼角度的深度解析？ 大家在項目中到處都在使用線程池做一些性能接口層次的優化，原先串行的多個遠程調用，因為rt過高，通過線程池批量異步優化，從而降低rt。還有像RocketMQ中broker啓動時，同時通過ScheduledThreadPoolExecutor線程池執行其他組件的定時任務，每隔一段時間處理相關的任務。線程池廣泛的應用在外面各種實際開發場景中，我們很多同學可能在
昵稱 得物技術
大家好，我是Java烘焙師。如何更新緩存和DB、做到性能和一致性的取捨，是一個很常見的話題。下面結合筆者的經驗和思考，系統性地總結一下緩存更新模式，講透講明白。 1、旁路緩存（cache-aside） 實現方案 查詢：先查緩存，查不到緩存時再查DB，並把DB內容寫入緩存、設置合適的過期時間 更新：先更新DB，再刪緩存；做到極致則需引入延遲雙刪機制 之所以不是先刪緩存、再更新DB，是因為在這
昵稱 Java烘焙師
緩存是提升 web 應用程序有效方法之一，尤其是用户受限於網速的情況下。提升系統的響應能力，降低網絡的消耗。當然，內容越接近於用户，則緩存的速度就會越快，緩存的有效性則會越高。 之前個人寫過 前端 api 請求緩存方案。介紹的了內存中的緩存以及過期邏輯。後續也寫過 手寫一個前端存儲工具庫，該工具利用了適配器處理了不同的存儲介質（內存，IndexedDB, localStorage 等）。 不過，在
昵稱 jump__jump
