背景 隨着業務的快速變化和技術的不斷髮展，系統面臨着諸多挑戰，例如流量峯值、依賴服務故障、硬件故障、網絡中斷、軟件缺陷等，這些因素都可能影響到系統的正常運行。在這種背景下，彈性設計（Resilience Design）應運而生。彈性設計是一種系統的設計和構建方法，系統的設計原則應該本着不信任外部資源（外部API服務、網絡設備、存儲、消息等）100%可用的原則，在關鍵處理路徑上針對上述可能發生故障的
背景 線上經常偶發死鎖問題，當時處理一張表，也沒有聯表處理，但是有兩個mq入口，並且消息體存在一樣的情況，頻率還不是很低，這麼一個背景，我非常容易懷疑到，兩個消息同時近到這一個事務裏面導致的，但是是偶發的，又模擬不出來什麼場景會導致死鎖，只能進行代碼分析，問題還原的方式去排查問題。 業務代碼簡化成下面 begin update test set yn = 0 where dm_code = "
一、前期準備～ 1、準備工作 !--mockito依賴--a dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version2.7.19/version scopetest/scope /dependency !-- junit依賴 -- dependency g
1. 前言 emmm，説起網絡知識學習肯定離不來wireshark工具，這個工具能夠幫助我們快速地定位網絡問題以及幫助正在學習網絡協議這塊的知識的同學驗證理論與實際的一大利器，平時更多的只是停留在初步的使用階段。也是利用部門內部的網絡興趣小組的討論機會，私下對wireshark的一些進階功能，比如專家模式、圖表等功能進行調研，並結合實際場景抓包分析對功能進行對照説明。 2. wireshark中
一、線程 1、什麼是線程 線程(thread)是操作系統能夠進行運算調度的最小單位。它被包含在進程之中，是進程中的實際 運作單位。一條線程指的是進程中一個單一順序的控制流，一個進程中可以併發多個線程，每條線 程並行執行不同的任務。 2、如何創建線程 2.1、JAVA中創建線程 /** * 繼承Thread類，重寫run方法 */ class MyThread extends Thread {
前言： 本文是由最近做的一個項目有感而發，因為之前做了一些技術棧的統一，為了用ant Design的pro-table，PC統一使用react，但是我們有一些老的項目是vue的，本次新頁面較多，老頁面的改動較少，除此之外老項目想換菜單，因此我們想借助本次機會用react開發，經過了幾番思考，發現本次很適合用微前端來完成本次需求，最終決定用react搭建一個基座（主應用），將原來的vue項目接入到基
1、前言 截至目前（2023年），Java8發佈至今已有9年，2018年9月25日，Oracle發佈了Java11，這是Java8之後的首個LTS版本。那麼從JDK8到JDK11，到底帶來了哪些特性呢？值得我們升級嗎？而且升級過程會遇到哪些問題呢？帶着這些問題，本篇文章將帶來完整的JDK8升級JDK11最全實踐。 2、為什麼升級JDK11 1）性能提升 更好的垃圾收機制、更快的類加載器, 加快應用
一 引言 JAVA1.8得益於Lambda所帶來的函數式編程，引入了一個全新的Stream流概念Stream流式思想類似於工廠車間的“生產流水線”，Stream流不是一種數據結構，不保存數據，而是對數據進行加工處理。Stream可以看作是流水線上的一個工序。在流水線上，通過多個工序讓一個原材料加工成一個商品。 二 常用方法介紹 2.1 獲取Stream流 所有的 Collection 集合都可以通
1.簡介 JSF業務線程池使用JDK的線程池技術，缺省情況下采用Cached模式（核心線程數20，最大線程數200）。此外，還提供了Fixed固定線程大小的模式，兩種模式均可設置請求隊列大小。 本文旨在通過一個簡化場景（“單服務應用”）下的負載測試，為“JSF業務線程池大小配置”提供基準測試結果，並形成一些普遍適用的結論。 本文的目標讀者包括需要合理配置JSF線程大小的壓測工程師、開發部署運維工程
技術的學習從不會到會的過程是最有意思的，也是體會最多的。一旦熟練了，知識變成了常識，可能就失去了記錄學習過程的最佳時機。 在我看來學習一門計算機語言和學習人類語言有很多共通之處。我們學習人類語言是從單個的詞開始，然後是簡單句子，通過不斷的與他人交互練習掌握語法和語言習慣。當熟練到一定程度就可以表達思想。計算的語言也差不多，熟悉關鍵詞，基本邏輯，標準庫，寫應用。只是溝通的對象是機器而已。 既然是學就
2021年上半年，擼了個rust cli開發的框架，基本上把交互模式，子命令提示這些cli該有的常用功能做進去了。項目地址：https://github.com/jiashiwen/interactcli-rs。 春節以前看到axum已經0.4.x了，於是想看看能不能用rust做個服務端的框架。 春節後開始動手，在做的過程中會碰到各種有趣的問題。於是記下來想和社區的小夥伴一起分享。社區裏的小夥伴大
用ChatGPT做了個Chrome Extension 最近科技圈兒最火的話題莫過於ChatGPT了。 最近又發佈了GPT-4，發佈會上的Demo着實吸睛。 筆記本上手畫個網頁原型，直接生成網頁。網友直呼：前端失業了！ 但我覺着啊，真就外行看熱鬧，內行看笑話。雖然ChatGPT很強大，但沒有經過針對某個領域自定義化過的模型真就沒啥用。。。 就比如寫代碼這事兒，我覺着還不如GitHub的Cop
一.啓動概述 瞭解整體Netty常用的核心組件後，並且對比了傳統IO模式。在對比過程中，找到了傳統IO對應Netty中是如何實現的。最後我們瞭解到在netty中常用的那些組件。 本文在瞭解下這些核心組件的前提下，進一步瞭解組件如何在整個服務器啓動過程如何被創建，如何組件之間配合來使用。首先也是先了解下大概服務端的啓動過程，並且在瞭解過程中我們帶着自己的問題去在學習過程中探尋答案。 1.1
一 引言 本文是京東到家自動化測試體系建設過程中的一些回顧和總結，刪減了部分系統設計與實踐的章節，保留了組織與文化相關的內容，整理成文，以饗讀者。 下面就以QA（Quality Assurance）的視角來探討工作中經常面臨的問題與挑戰。 關於軟件質量，不知道你有沒有以下困惑： 西醫中“頭疼醫頭，腳疼醫腳”的思路在研發團隊中往往不能奏效。中醫的整體辯證論治往往是解決問題的良方。其根本還是思考維度
如何設計一個接口？是在我們日常開發或者面試時經常問及的一個話題。 很多人覺得這不就是CRUD，能實現不就行了。單純實現來説，並非難事，但要做到易用、易擴展、易維護並不是一件簡單的事。這裏並不強調一些個接口設計的原則或者設計方法，僅從如何設計一個好的接口出發，簡單討論。 1、命名規範 我們寫代碼，不僅僅是為了實現當前的功能，也要有利於後面的維護。所謂的維護，就是代碼不僅僅是寫給自己看的，也是給別人看
背景 在移動端頁面中，由於屏幕空間有限，導航條扮演着非常重要的角色，提供了快速導航到不同頁面或功能的方式。用户也通常會在導航條中尋找他們感興趣的內容，因此導航條的曝光率較高。在這樣的背景下，提供一個動態靈活的導航條，為產品賦能，變得尤其重要。 使用原生導航欄現狀 拿iOS原生導航條為例，導航條作為頁面進出棧的根視圖連接器，以及生命週期的管理器。尤其是在作為webView Controller的父容
起初沒有人在意這場GC,直到它影響到了每一天! 前言 本文記錄了一次排查FullGC導致的TP99過高過程,介紹了一些排查時思路,線索以及工具的使用,希望能夠幫助一些新手在排查問題沒有很好的思路時,提供一些思路,讓小白也能輕鬆解決FullGC問題,文中實際提到的參數配置不一定適合其他業務場景,在調優自己的項目時還是需要實際試驗過才能得出最佳參數配置 我也是小白,如有不合理的地方,歡迎大佬們進行指正
最近牽頭在梳理部門的系統架構合理性，開始工作之前，我首先想到的是如何定義架構合理性？ 從研發的角度來看如果系統上下文清晰、應用架構設計簡單、應用拆分合理應該稱之為架構合理。 基於以上的定義可以從以下三個方面來梳理評估： 1、系統的上下文清晰：明確的知道和周圍系統的調用關係，數據同步機制； 2、應用架構設計簡單：架構分層合理，功能定位清晰，不會出現功能邊界之外事情； 3、應用拆分合理：系統內的應用粒
問題介紹 在日常的開發過程中，我們不可避免地會使用到 JDK8 之前的 Date 類，在格式化日期或解析日期時就需要用到 SimpleDateFormat 類，但由於該類並不是線程安全的，所以我們常發現對該類的不恰當使用會導致日期解析異常，從而影響線上服務可用率。 以下是對 SimpleDateFormat 類不恰當使用的示例代碼： package com.jd.threadsafe; impo
1. 現狀·問題 你還記得你排查jar衝突的付出麼？ 為了有效控制jar包更新帶來的未知jar引入和變動，我們經常使用dependency-tree來查看依賴關係排查問題，通常是出現問題再被動分析和排查，此時人力成本是巨大的，同時系統已出問題，沒有後悔藥。 2. 分析原因 jar包依賴是異變的，且隱形的，jar衝突導致的問題經常發生，研發無法每次都關注其變化。 3. 採取措施 採用“敏捷”思想，小
1.前言 最近小組在開展讀書角活動，我們小組選的是《深入理解JVM虛擬機》，相信這本書對於各位程序猿們都不陌生，我也是之前在學校準備面試期間大致讀過一遍，emm時隔多日，對裏面的知識也就模糊了。這次開始的時候從前面的JDK發展史和JVM虛擬機家族着手，之前都是粗略讀過，這次通過查閲相關資料並收集在每一個JDK版本演化期間所發生的的一些趣聞，發現還是比較有意思的，以下是關於有關JDK發展史的總結分享
前言 自 2014 年發佈以來， JDK 8 一直都是相當熱門的 JDK 版本。其原因就是對底層數據結構、JVM 性能以及開發體驗做了重大升級，得到了開發人員的認可。但距離 JDK 8 發佈已經過去了 9 年，那麼這 9 年的時間，JDK 做了哪些升級？是否有新的重大特性值得我們嘗試？能否解決一些我們現在苦惱的問題？帶着這份疑問，我們進行了 JDK 版本的調研與嘗試。 新特性一覽 現如今的 JDK
一. 現狀·問題 針對現如今高併發場景的業務系統，“併發問題” 終歸是必不可少的一類（佔比接近10%），每次出現問題和事故後，需要耗費大量人力成本排查分析並修復。那如果能在事前儘可能避免豈不是很香？ 二. 分析原因 當前併發測試多數依賴測試人員進行腳本測試，同時還依賴了研發和產品識別出併發操作的場景用例。 對於併發測試，大概兩條路子： 所有修改同樣數據的命令式接口都測一遍？【耗費巨大
現在市面上有各式各樣的分佈式定時任務，每個都有其獨特的特點，我們這邊的項目因為一開始使用的是分佈式開源調度框架TBSchedule，但是這個框架依賴ZK，由於ZK的不穩定性和項目老舊無人維護，導致我們的定時任務會偶發出現異常,比如：任務停止、任務項丟失、任務不執行等； 每逢618大促，在單量很大的情況下，如果出現定時任務異常，會導致訂單的積壓，進而導致訂單的履約時效，嚴重影響商家的履約效率，造成訂
