原创 排查頻繁的FulGC

問題 前段時間發現線上的一個dubbo服務Full GC比較頻繁,大約每兩天就會執行一次Full GC。 Full GC的原因 我們知道Full GC的觸發條件大致情況有以下幾種情況: 1.程序執行了System.gc() //建

原创 破壞單例模式的三種方式

單例模式的定義: 單例模式,是一種常用的軟件設計模式。在它的核心結構中只包含一個被稱爲單例的特殊類。通過單例模式可以保證系統中,應用該模式的類一個類只有一個實例。即一個類只有一個對象實例。 在java中,單例模式我們常用的有三種(

原创 java虛擬機如何知道哪些對象需要被回收

java虛擬機是通過可達性分析算法來判定對象是否存活。 當一個對象到GC Roots沒有任何引用鏈相連,或者說從GC Roots到這個對象不可達時,這個對象將會被判定爲是可回收的對象。 在Java語言中,可作爲GC Roots的對

原创 白話零拷貝

sendfile()這個系統調用 是在兩個文件描述符之間直接傳遞數據(這個操作是完全在內核態進行),從而避免了數據在內核緩衝區和用戶緩衝區之間的拷貝,稱之爲零拷貝,操作效率很高 --------------------------

原创 java虛擬機爲什麼要分代回收

堆內存是虛擬機管理的內存中最大的一塊,也是垃圾回收最頻繁的一塊區域,我們程序所有的對象實例都存放在堆內存中。給堆內存分代是爲了提高對象內存分配和垃圾回收的效率。 試想一下,如果堆內存沒有區域劃分,所有的新創建的對象和生命週期很長的

原创 http中get和post性能對比

get和post在面試過程中一般都會問到,一般的區別: 1.post更安全(不會作爲url的一部分,不會被緩存、保存在服務器日誌、以及瀏覽器瀏覽記錄中) 2.post發送的數據量更大(get有url長度限制) 3.post能發送更

原创 爲什麼redis單線程卻能支撐高併發

redis 和 memcached 有什麼區別?redis 的線程模型是什麼?爲什麼 redis 單線程卻能支撐高併發? 這個是問 redis 的時候,最基本的問題吧,redis 最基本的一個內部原理和特點,就是 redis 實際

原创 cookie的安全性

什麼是cookie 指某些網站爲了辨別用戶身份、進行session跟蹤而存儲在用戶本地終端上的數據(通常經過加密)。(注:此定義來自百度百科) cookie對於登錄的效果 排除用戶手動刪除瀏覽器cookie以及cookie未過期的

原创 redis爲什麼選擇了跳躍表而不是紅黑樹

Redis只在兩個地方用到了跳躍表,一個是實現有序集合鍵(zset),另一個是在集羣節點中用作內部數據結構,除此之外,跳錶在Redis裏面沒有其他用途。 但是爲什麼用跳錶而不用紅黑樹呢?猜想如下: 1)在做範圍查找的時候,平衡樹比

原创 通過前序與中序遍歷序列構造二叉樹

題目: 根據一棵樹的前序遍歷與中序遍歷構造二叉樹。 注意: 你可以假設樹中沒有重複的元素。 例如,給出: 前序遍歷 preorder = [3,9,20,15,7] 中序遍歷 inorder = [9,3,15,20,7] 返回

原创 Zookeeper選舉與消息廣播

ZAB協議概述 在前面的文章中,介紹了經典的分佈式數據一致性算法Paxos算法,但事實上zookeeper並沒有採用完全的Paxos算法,而是採用了一種稱爲Zookeeper Atomic Broadcast(ZAB,zookee

原创 Java反射原理簡析

Java的反射機制允許我們動態的調用某個對象的方法/構造函數,獲取某個對象的屬性等,而無需在編碼時確定調用的對象。這種機制在我們常用的框架中也非常常見。 1.原理簡介 類actionClass = Class.forName(“

原创 Zookeeper腦裂

什麼是腦裂 腦裂(split-brain)就是“大腦分裂”,也就是本來一個“大腦”被拆分了兩個或多個“大腦”,我們都知道,如果一個人有多個大腦,並且相互獨立的話,那麼會導致人體“手舞足蹈”,“不聽使喚”。 腦裂通常會出現在集羣環境

原创 InnoDB插入緩衝

InnoDB存儲引擎有三大特性非常令人激動,它們分別是插入緩衝、兩次寫和自適應哈希,本篇文章先介紹第一個特性 - 插入緩衝(insert buffer) 在上一篇《MySQL - 淺談InnoDB存儲引擎》中,我們可以看到在Inn

原创 MySQL的預讀機制

一、預讀機制 InnoDB在I/O的優化上有個比較重要的特性爲預讀,預讀請求是一個i/o請求,它會異步地在緩衝池中預先回遷多個頁面,預計很快就會需要這些頁面,這些請求在一個範圍內引入所有頁面。InnoDB以64個page爲一個ex