原创 JVM鎖升級的過程
當一個Java類實例對象(obj)被 synchronized(obj){...}包裝成爲同步監視器對象(即鎖對象)時,在不同程度的線程競爭情況下,它對象頭(Header)中的Mark Word部分的變化情況如下表所示(即JVM鎖升級的
原创 Web服務停止並卸載後其啓動的線程還在跑的可能原因
package org.example; import javax.servlet.ServletConfig; import javax.servlet.ServletException; import javax.servlet.a
原创 應用系統性能考慮點
在有限開支下選擇合適的硬件服務器和網絡帶寬:跑數據庫的、跑中間件的、跑應用本身的、跑負載均衡器的,它們側重的硬件參數會有所差別,要求的網絡帶寬也會不同; 着重考慮數據庫的參數配置、數據文件存儲方式、數據文件IO、存儲分區等; 應用系統自身
原创 Tomcat版本對照表
Tomcat版本 6.0 7.0 8.0 8.5 9.0 10.1 11.0 JDK ≥5.0 ≥6.0 ≥7.0 ≥7.0 ≥8.0 ≥11
原创 OpenJDK17.0.8字節碼解讀樣例
因爲JDK17將會成爲未來5至10年裏Java應用的主流JDK,剛好閒着沒事,就想着將《深入理解Java虛擬機》一書中關於字節碼的解讀樣例在OpenJDK17.0.8上看看變化有多大! 先把實驗環境說明一下: OS:Window
原创 Unity3D 使用帶剛體組件的預製體配合腳本自動生成一面牆時上層牆體被彈飛
異常效果如下圖所示: 預製體是一個正方體(Cube),其參數設置如下圖所示: 控制牆面生成的C#腳本如下所示: using System.Collections; using System.Collections.Generic; u
原创 Unity3D 播放運行時遊戲對象往上飛了
我的原因是不小心給主攝像機(Main Camera)添加了剛體(Rigidbody)組件,導致播放運行時攝像機受重力作用往下掉,造成遊戲(Game)視圖窗口內看見的遊戲對象往上飛了!如下圖所示: 把掛在攝像機的上剛體(Rigidbod
原创 CentOS7.9下KubeKey安裝Kubesphere3.3.2
建議準備一臺 8 核 CPU 和 16 GB 內存 乾淨的CentOS7.9,內核由升級至5.4.+ 第一步禁用防火牆: systemctl disable firewalld --now 第二步配置可用的DNS: #先用以下命令找到
原创 MySQL的RR和RC事務隔離級別加鎖類型驗證
先上結輪:MySQL5.7數據庫Innodb引擎在默認的 REPEATABLE-READ(可重複讀RR) 事務隔離級別時,事務修改類操作對於where範圍條件鎖定的行區加的是Next-Key Lock 即臨鍵間隙鎖,對於確切條件鎖定的行
原创 Eureka高可用集羣服務端和客戶端配置
微服務應用中,生產環境一般都需要保障服務註冊中心的高可用!高可用也分好幾個等級,例如:同數據中心(可用Zone區)高可用——》同地域(Region)跨數據中心(可用Zone區)高可用——》全國跨地域(Region)跨數據中心(可用Zon
原创 基於Alpine Linux鏡像製作小體積JDK鏡像
爲了提高鏡像的上傳和分發速度,我們通常會努力把自己的鏡像做得儘量小! Java開發的jar包應用需要運行在JDK上(實際只需要JRE裏的java運行工具和JVM,JDK中包含了JRE),而java運行工具和JVM又需要運行在操作系統
原创 Docker Desktop配合WSL和IDEA進行Java服務的打包+鏡像構建+容器運行測試
在Windows10 22H2+的版本可以使用WSL了(Windows Subsystem for Linux 或叫 Windows Support Linux,即Windows內置的Linux子系統)!它對於在Windows下工作的容
原创 Windows10+新安裝WSL的root密碼設置及文件複製
Windows10+上安裝WSL時,經常可能會直接設置了一個普通用戶和密碼,但是在後繼的工作過程中很可能會用到root賬號。但由於安裝過程中未設置過root賬號的密碼,切換不了root: Installing, this may take
原创 Docker客戶端登錄啓用了HTTPS的Harbor要注意的事項
首先在Harbor將要部署的主機上創建Harbor專用的證書目錄: mkdir -p /data/harbor/certs/cd /data/harbor/certs 生成CA證書的私鑰 openssl genrsa -out
原创 爲K8S集羣準備Ceph存儲
隨着K8S存儲接口逐漸成熟並順勢推出CSI接口規範後,原來“in-tree”(樹內)模式的很多存儲插件也逐步遷移到了“out-of-tree”(樹外)模式的CSI插件上,甚至有些原來支持的存儲卷類型都被直接移除了(例如在K8S v1.2