1. 程式人生 > >Camera影象處理原理及例項分析-重要影象概念

Camera影象處理原理及例項分析-重要影象概念

 

Camera影象處理原理及例項分析

作者:劉旭暉  [email protected]  轉載請註明出處

BLOG:http://blog.csdn.net/colorant/

做為拍照手機的核心模組之一,camera sensor 效果的調整,涉及到眾多的引數,如果對基本的光學原理及 sensor 軟/硬體對影象處理的原理能有深入的理解和把握的話,對我們的工作將會起到事半功倍的效果。否則,缺乏了理論的指導,只能是憑感覺和經驗去碰,往往無法準確的把握問題的關鍵,不能掌握 sensor 除錯的核心技術,無法根本的解決問題。

1.1  色彩感應及校正

1.1.1  原理

人眼對色彩的識別,是基於人眼對光譜存在三種不同的感應單元,不同的感應單元對不同波段的光有不同的響應曲線的原理,通過大腦的合成得到色彩的感知。  一般來說,我們可以通俗的用 RGB三基色的概念來理解顏色的分解和合成。

理論上,如果人眼和 sensor 對光譜的色光的響應,在光譜上的體現如下的話,基本上對三色光的響應,相互之間不會發生影響,沒有所謂的交叉效應。

但是,實際情況並沒有如此理想,下圖表示了人眼的三色感應系統對光譜的響應情況。可見 RGB的響應並不是完全獨立的。

下圖則表示了 Kodak 某相機光譜的響應。可見其與人眼的響應曲線有較大的區別。

1.1.2  對 sensor的色彩感應的校正

既然我們已經看到 sensor 對光譜的響應,在 RGB各分量上與人眼對光譜的響應通常是有偏差的,當然就需要對其進行校正。不光是在交叉效應上,同樣對色彩各分量的響應強度也需要校正。通常的做法是通過一個色彩校正矩陣對顏色進行一次校正。

該色彩校正的運算通常由 ISP 完成,軟體通過修改相關暫存器得到正確的校正結果。值得注意的一點是,由於 RGB  -> YUV的轉換也是通過一個 3*3 的變換矩陣來實現的,所以有時候這兩個矩陣在 ISP 處理的過程中會合並在一起, 通過一次矩陣運算操作完成色彩的校正和顏色空間的轉換。

1.2  顏色空間

1.2.1  分類

實際上顏色的描述是非常複雜的,比如 RGB三基色加光系統就不能涵蓋所有可能的顏色,出於各種色彩表達,以及色彩變換和軟硬體應用的需求,存在各種各樣的顏色模型及色彩空間的表達方式。這些顏色模型,根據不同的劃分標準,可以按不同的原則劃分為不同的類別。

對於 sensor 來說,我們經常接觸到的色彩空間的概念,主要是 RGB , YUV這兩種(實際上, 這兩種體系包含了許多種不同的顏色表達方式和模型, 如 sRGB, Adobe RGB, YUV422, YUV420 …) , RGB如前所述就是按三基色加光系統的原理來描述顏色, 而YUV則是按照  亮度,色差的原理來描述顏色。

1.2.1.1  RGB <-> YUV的轉換

不比其它顏色空間的轉換有一個標準的轉換公式,因為 YUV在很大程度上是與硬體相

關的,所以 RGB與 YUV的轉換公式通常會多個版本,略有不同。

常見的公式如下

PAL 制:

Y=0.299R+0.587G+0.114B  

U=0.493(B-Y) = -0.15R-0.29G+0.44B  

V=0.877(R-Y) = 0.62R-0.52G-0.10B

此外,還有,NTSC制:

但是這樣獲得的 YUV值存在著負值以及取值範圍上下限之差不為 255 等等問題,不利於計算機處理,所以根據不同的理解和需求,通常在軟體處理中會用到各種不同的變形的公式 :

體現在 Sensor 上,我們也會發現有些 Sensor 可以設定 YUV 的輸出取值範圍。原因就在於此。 從公式中,我們關鍵要理解的一點是,UV  訊號實際上就是藍色差訊號和紅色差訊號,進而言之,實際上一定程度上間接的代表了藍色和紅色的強度,理解這一點對於我們理解各種顏色變換處理的過程會有很大的幫助。

1.3  白平衡

1.3.1  色溫

色溫的定義:將黑體從絕對零度開始加溫,溫度每升高一度稱為 1 開氏度(用字母 K來表示),當溫度升高到一定程度時候,黑體便輻射出可見光,其光譜成份以及給人的感覺也會著溫度的不斷升高發生相應的變化。於是,就把黑體輻射一定色光的溫度定為發射相同色光光源的色溫。

隨著色溫的升高,光源的顏色由暖色向冷色過渡,光源中的能量分佈也由紅光端向藍光端偏移。

值得注意的是,實際光源的光譜分佈各不相同,而色溫只是代表了能量的偏重程度,並不反映具體的光譜分佈,所以即使相同色溫的光源,也可能引起不同的色彩反應。 人眼及大腦對色溫有一定的生理和心理的自適應性, 所以看到的顏色受色溫偏移的影響較小,而 camera的 sersor 沒有這種能力,所以拍出來的照片不經過白平衡處理的話,和人眼看到的顏色會有較大的偏差(雖然人眼看到的和白光下真實的色彩也有偏差)。

太陽光色溫隨天氣和時間變化的原因,與不同頻率光的折射率有關:

波長長的光線,折射率小,透射能力強,波長短的光線,折射率大,容易被散射,折射率低,這也就是為什麼交通燈用紅色,防霧燈通常是黃色,天空為什麼是藍色的等等現象的原因。

知道了這一點,太陽光色溫變化的規律和原因也就可以理解和分析了,留給大家自己思考。

1.3.2  色溫變化時的色彩校正

所以從理論上可以看出,隨著色溫的升高,要對色溫進行較正,否則,物體在這樣的光線條件下所表現出來的顏色就會偏離其正常的顏色,因此需要降低 sensor 對紅色的增益,增加 sersor 對藍光的增益。 同時在調整引數時一定程度上要考慮到整體亮度的要保持大致的不變,即以 YUV 來衡量時,Y 值要基本保持不變,理論上認為可以參考 RGB->YUV 變換公式中,RGB三分量對 Y值的貢獻,從而確定 RGAIN 和 BGAIN 的變化的比例關係。但實際情況比這還要複雜一些,要考慮到不同 sensor 對 R,B的感光的交叉影響和非線性,所以最佳值可能和理論值會有一些偏差。

1.3.3  自動白平衡原理

1.3.3.1  原理

自動白平衡是基於假設場景的色彩的平均值落在一個特定的範圍內, 如果測量得到結果偏離該範圍,則調整對應引數,校正直到其均值落入指定範圍。該處理過程可能基於 YUV空間,也可能基於 RGB空間來進行。對於 Sensor 來說,通常的處理方式是通過校正 R/B增益,使得 UV值落在一個指定的範圍內。從而實現自動白平衡。

1.3.3.2  特殊情況的處理

在自動白平衡中,容易遇到的問題是,如果拍攝的場景,排除光線色溫的影響,其本身顏色就是偏離平均顏色值的,比如大面積的偏向某種顏色的圖案如:草地,紅旗,藍天等等,這時候,強制白平衡將其平均顏色調整到灰色附近,影象顏色就會嚴重失真。

因此,通常的做法是:在處理自動白平衡時,除了做為目標結果的預期顏色範圍外,另外再設定一對源影象的顏色範圍闕值,如果未經處理的影象其顏色均值超出了該闕值的話,根本就不對其做自動白平衡處理。由此保證了上述特殊情況的正確處理。

可見,這兩對闕值的確定對於自動白平衡的效果起著關鍵性的作用。

1.3.4  某程式碼的例子

可以看到隨著色溫的升高,其變化規律基本符合上節中的理論分析。不過這裡多數引數與理論值都有一些偏差,其中日光燈的色溫引數設定與理論值有較大的偏差,實際效果也證明該日光燈的引數設定使得在家用日光燈環境下拍攝得到的照片顏色偏藍。 修改其引數後實拍效果明顯改善。(再查一些資料可以看到通常會有兩種熒光燈色溫 4000  和 5000K,目前我所接觸到的應該是 5000K居多)。

1.3.5  除錯和驗證

具體引數的調整,應該在燈箱環境下,使用各種已知色溫的標準光源對標準色卡拍攝,在 Pc 機上由取色工具測量得到其與標準色板的 RGB分量上的色彩偏差,相應的調整各分量增益的比例關係。為了更精確的得到結果,曝光量增益的設定在此之前應該相對準確的校正過。

1.4  顏色相關特效處理

1.4.1  grayscale (灰階)

灰階圖的效果就是將彩色圖片轉換為黑白圖片。

1.4.1.1  理論

理論上,在 YUV空間,將 UV分量丟棄,只保留 Y分量,這樣就可以得到黑白影象,這也是彩色電式機訊號能相容黑白電視機的原理。如下圖理論上 Y 值一樣的顏色(右邊是用 acdsee 轉成灰度圖的效果),在 grayscale 模式下看應該是一樣的顏色。

演算法上的操作,理論上應該把 UV值改成灰色對應數值就可以了。不過根據軟體演算法和硬體結構的不同,具體程式碼也會有不同。

1.4.2  sepia / sepiagreen / sepiablue

某平臺手機上所謂的復古(綠,藍)就是在灰階的基礎上,對 UV值做了一個 offset,將灰度圖轉換成某種顏色的梯度圖。理論上為了獲得藍色效果,應該增加藍色差訊號,減小紅色差訊號。即增大 U,減小 V。

以 sepiablue 效果為例,這裡的位元組的 MSB表示符號位:所以 88 為 88,158 為-30。

      SET_HUE_U_GAIN(0);  

      SET_HUE_V_GAIN(0);  

      SET_HUE_U_OFFSET(88);

      SET_HUE_V_OFFSET(158);

1.4.3  negative

所謂負片效果,就是將影象的顏色反轉,看起來就像是在看膠片底片時的效果。這從理論上也很容易理解和處理,就是在 RGB空間,取其補色,具體的操作就是用 255 分別減去RGB得到新的 RGB值。通常會在 ISP 中實現該功能。

理解了原理,要做出其它顏色變換方面的效果就很容易了。 基本上,在顏色校正和處理方面,需要考慮的相關引數大致包括:

自動 WB 上下限,自動白平衡時的目標範圍,RGB gain, UV gain, UV offset, color correction.有些還會有saturation  和 hue 相關的設定。

從 sensor 或 ISP 硬體處理的流程上說, 通常方向是先做 RGB gain, 再做 color correction,最後做 YUV空間的處理。所以調整效果的時候,為了減少引數之間的相互影響,基本上也可以按這個順序來調整引數。

1.5  亮度感應及曝光

1.5.1  感光寬容度

從最明亮到最黑暗,假設人眼能夠看到一定的範圍,那麼膠片(或 CCD 等電子感光器件)所能表現的遠比人眼看到的範圍小的多,而這個有限的範圍就是感光寬容度。

人眼的感光寬容度比膠片要高很多,而膠片的感光寬容度要比數碼相機的 ccd 高出很多!瞭解這個概念之後,我們就不難了解,為什麼在逆光的條件下,人眼能看清背光的建築物以及耀眼的天空雲彩。而一旦拍攝出來,要麼就是雲彩顏色絢爛而建築物變成了黑糊糊的剪影,要麼就是建築物色彩細節清楚而原本美麗的雲彩卻成了白色的一片。

再看人眼的結構,有瞳孔可以控制通光量,有桿狀感光細胞和椎狀感光細胞以適應不同的光強,可見即使人眼有著很高的感光寬容度,依然有亮度調節系統,以適應光強變化。

那麼對於 camera sensor 來說,正確的曝光就更為重要了!

1.5.2  自動曝光和18%灰

對於 sensor 來說,又是如何來判斷曝光是否正確呢?很標準的做法就是在 YUV空間計算當前影象的 Y值的均值。調節各種曝光引數設定(自動或手動),使得該均值落在一個目標值附近的時候,就認為得到了正確的曝光。

那麼如何確定這個 Y的均值,以及如何調整引數使得sensor 能夠將當前影象的亮度調整到這個範圍呢?

這就涉及到一個概念 18%灰,一般認為室內室外的景物,在通常的情況下,其平均的反光係數大約為 18%,而色彩均值,如前所述,可以認為是一種中灰的色調。這樣,可以通過對反光率為 18%的灰板拍攝,調整曝光引數,使其顏色接近為中等亮度的灰色(Y 值為 128)。然後,對於通常的景物,就能自動的得到正確的曝光了。

當然這種自動判斷曝光引數的 AE 功能不是萬能的,對於反光率偏離通常均值的場景,比如雪景,夜景等,用這種方法就無法得到正確的曝光量了。所以在 sensor 的軟體處理模組中,通常還會提供曝光級別的設定功能,強制改變自動曝光的判斷標準。比如改變預期的亮度均值等。

1.5.3  曝光級別設定

在多數數碼相機和拍照手機上都可以看到曝光級別設定的功能,如前所述,這種設定實際上是在自動曝光的基礎上給使用者提供一定的曝光控制能力,強制改變 camera sensor 的曝光判斷標準,獲得使用者想要的效果。

通常的做法就是改變 Y值均值的預期值,使得 sensor 在自動曝光時以新的 Y預期值為目標,自動調整 Exptime  和 AG。

1.5.4  gamma 校正

曝光的均值正確了,不代表整體影象的亮度分佈就和人眼所看到的保持一致了。

事實上,人眼對亮度的響應並不是一個線性的比例關係,而各種涉及到光電轉換的裝置的輸入輸出特性曲線一般也是非線性的,且表現為冪函式的形式:y=xn  ,  所以整個圖系統的傳遞函式是一個冪函式:g= g1×g2×…×gn 。

對於 sensor 來說,其響應倒是接近為線性關係,所以為了在各種裝置上正確輸出符合人眼對亮度的響應的影象,就需要進行校正。

冪函式的指數的倒數就是通常所說的 gamma 值。

校正的函式可以表示為 ,通常對於 Window 的輸出顯示系統,gamma 值為 2.2,而對於蘋果的輸出顯示系統和列印系統來說,gamma 值為 1.8。

實際上,sensor 在做 gamma 校正的時候,通常也一併作了從raw 格式的 10bit 的資料到8bit 資料的轉換,所以這時候的公式可以表示為

由於指數運算需要消耗大量的 CPU時間,所以實際的做法,往往是將 gamma 曲線用比如 12 段線段進行擬合。這樣只需要儲存 13 個點的資料,用線性變換或查表的方式進行gamma 校正。我司多數平臺的 gamma 校正就是採用了後者的方法。要調整 gamma 校正實際上也就是調整這 13 個點的數值。

原則上,在拍攝如下圖灰階的色板時,能分辨出的級數越多越好。

1.5.5  對比度

對比度的調整在一定程度上說,其實也就是對 gamma 曲線的調整,增大對比度就是提高 Gamma 值。對於影象處理來說,也有在硬體 gamma 校正後,單獨由軟體再進行一次類似的冪函式變換來調整對比度。 、

1.5.6  曝光引數的調整

曝光強度的調整,可以通過改變曝光時間,也可以通過改變亮度增益 AG 來實現。

曝光時間受到幀頻的限制,比如攝像時要求 15 幀每秒的話,這時候曝光時間最長就不能超過 1/15s,可能還有別的條件限制,實際的曝光時間還要短,在光線弱的情況下,單獨調整曝光時間就無法滿足幀頻的需要了。

這時候還可以調整增益 AG,來控制曝光的增益,降低曝光時間。但是,這樣做的缺點是以犧牲影象質量為代價的,AG 的增強,伴隨的必然是信噪比的降低,影象噪聲的增強。

所以,以影象質量為優先考慮的時候,曝光引數的調節通常是優先考慮調節曝光時間,其次在考慮曝光增益。當然曝光時間也不能過長以免由於抖動造成影象的模糊,而在拍攝運動場景時,對曝光時間的要求就更高了。

1.6  抗噪處理

AG  的增大,不可避免的帶來噪點的增多,此外,如果光線較暗,曝光時間過長,也會增加噪點的數目(從數碼相機上看,主要是因為長時間曝光,感光元件溫度升高,電流噪聲造成感光元件噪點的增多),而感光元件本身的缺陷也是噪點甚至壞點的來源之一。因此,通常 sensor 整合或後端的 ISP 都帶有降噪功能的相關設定。

1.6.1  啟動時機

根據噪點形成的原因,主要是 AG 或 Exptime 超過一定值後需要啟動降噪功能,因此通常需要確定這兩個引數的闕值,過小和過大都不好。

從下面的降噪處理的辦法將會看到,降噪勢附帶的帶來影象質量的下降,所以過早啟動降噪功能, 在不必要的情況下做降噪處理不但增加處理器或 ISP 的負擔, 還有可能適得其反。而過遲啟動降噪功能,則在原本需要它的時候,起不到相應的作用。

1.6.2  判定原則和處理方式

那麼如何判定一個點是否是噪點呢?我們從人是如何識別噪點的開始討論, 對於人眼來說,判定一個點是噪點,無外乎就是這一點的亮度或顏色與邊上大部分的點差異過大。從噪點產生的機制來說,顏色的異常應該是總是伴隨著亮度的異常,而且對亮度異常的處理工作量比顏色異常要小,所以通常 sensor ISP 的判定原則是一個點的亮度與周圍點的亮度的差值大於一個闕值的時候,就認為該點是一個噪點。

處理的方式,通常是對周圍的點取均值來替代原先的值,這種做法並不增加資訊量,類似於一個模糊演算法。

對於高階的數碼相機,擁有較強的影象處理晶片,在判定和處理方面是否有更復雜的演算法,估計也是有可能的。比如亮度和顏色綜合作為標準來判定噪點,採用運算量更大的插值演算法做補償,對於 sensor 固有的壞點,噪點,採用遮蔽的方式拋棄其資料(Nikon 就是這麼做的,其它廠商應該也如此)等等。

1.6.3  效果

對於手機 sensor 來說,這種降噪處理的作用有多大,筆者個人認為應該很有限,畢竟相對數碼相機,手機 sensor 的鏡頭太小,通光量小,所以其基準 AG 勢必就比相機的增益要大(比如相當於普通家用數碼相機 ISO800 的水平),這樣才能獲得同樣的亮度,所以電流噪聲帶來的影響也就要大得多。這樣一來,即使最佳情況,噪點也會很多,資料本身的波動就很大,這也就造成我們在手機照片上勢必會看到的密密麻麻的花點,如果全部做平均,降低了噪點的同時,影象也會變得模糊,所以手機噪點的判斷闕值會設得比較高,以免涉及面過大,模糊了整體影象。這樣一來一是資料本身就差,二是降噪的標準也降低了,造成總體效果不佳。

1.7  數碼變焦

數碼變焦可以有兩種形式:

其一,是通過插值演算法,對影象進行插值運算,將影象的尺寸擴大到所需的規格,這種演算法就其效果而言,並不理想,尤其是當使用在手機上的時候,手機上的攝像頭本身得到的資料就有較大的噪聲,再插值的話,得到的影象幾乎沒法使用。實際上,即使是數碼相機的數碼變焦功能也沒有太大的實用價值。如果插值演算法沒有硬體支援,則需要在應用層實現。我司某平臺的數碼變焦用的就是該種辦法。

其二,其實是一種偽數碼變焦的形式,當攝像頭不處在最大解析度格式的情況下,比如130 萬畫素的 sensor 使用 640*480 的規格拍照時,仍舊設定 sersor 工作在 1280*960 的解析度下,而後通過採集中央部分的影象來獲取 640*480 的照片,使得在手機上看來所拍物體尺寸被放大了一倍。也有很多手機採用的是這種數碼變焦方式,這種辦法幾乎不需要額外的演算法支援,對影象質量也沒有影響,缺點是隻有小尺寸情況下可以採用。此外在 DV方式下也可以實現所謂的數碼變焦放大拍攝功能。(這應該是一個賣點,對 Dv 來說,這種數碼變焦還是有實際意義的)。

要採用這種變焦模式,驅動需要支援 windowing 功能,獲取所需部分的 sensor 影象資料。

1.8  頻閃抑制功能

1.8.1  何謂頻閃

日常使用的普通光源如白熾燈、日光燈、石英燈等都是直接用 220/50Hz 交流電工作,每秒鐘內正負半周各變化 50 次,因而導致燈光在1 秒鐘內發生 100(50×2)次的閃爍,再加上市電電壓的不穩定,燈光忽明忽暗,這樣就產生了所謂的“頻閃” 。

下表顯示了幾種光源的光強波動情況:

因為人眼對光強變化有一定的遲滯和適應性,所以通常看不出光源的亮度變化。但是依然還是會增加眼睛的疲勞程度。所以市場上才會有所謂的無頻閃燈銷售。

1.8.2  對頻閃的抑制

對於 camera sensor 來說,沒有人眼的遲滯和適應過程,所以對光源亮度的變化是比較敏感的。如果不加抑制,在預覽和 DV模式下,可能會有明顯的影象的明亮變化閃爍的現象發生。

如何解決呢?考慮到頻閃的週期性,在一個週期內,光源亮度的累積值,應該是大體一致的,所以,如果控制曝光的時間是頻閃週期的整倍數,那麼每一幀影象的亮度就大體是一致的了,這樣就可以有效地抑制頻閃對影象亮度的影響。

所以,在自動曝光的模式下,sensor 會根據頻閃的頻率,調整曝光時間為其週期的整倍數。 因為各地的交流電的頻率不同,所以有 50Hz/60Hz 之分。

在具體設定相關 Sensor 暫存器的時候,要根據電流頻率和 sensor 的時鐘頻率,解析度等,計算出頻閃週期對應的時鐘週期數等。

相關推薦

Camera影象處理原理例項分析-重要影象概念

  Camera影象處理原理及例項分析 作者:劉旭暉  [email protected]  轉載請註明出處 BLOG:http://blog.csdn.net/colorant/ 做為拍照手機的核心模組之一,camera sensor 效果的調整,涉及到眾多

圖的BFS和DFS原理例項分析(java)

BFS和DFS是圖的兩種遍歷方式,是最簡單的圖搜尋演算法。 本文將給出給出BFS和DFS的以下幾種實現方式: 1、使用佇列Queue實現圖的BFS遍歷 2、遞迴實現圖的DFS遍歷 3、使用棧Stack迭代實現圖的DFS遍歷 一、BFS(廣度優先搜尋

K最近鄰分類演算法原理例項分析

目錄 概述 原理 要點 例項 1、概述 K最近鄰(k-Nearest Neighbor,KNN),指導思想是“近朱者赤,近墨者黑”,由你的鄰居來推斷出你的類別,KNN分類演算法是最簡單的機器學習演算法。 2、原理 從訓練集中找到和新資料最接近的k條記錄

【機器學習】LDA線性判別分析原理例項

1、LDA的基本原理 LDA線性判別分析也是一種經典的降維方法,LDA是一種監督學習的降維技術,也就是說它的資料集的每個樣本是有類別輸出的。這點和PCA不同。PCA是不考慮樣本類別輸出的無監督降維技術。LDA的思想可以用一句話概括,就是“*投影后類內方

SylixOS中select原理使用分析

SylixOS select 1. select接口簡介 1.1 select接口使用用例 select是操作系統多路I/O復用技術實現的方式之一。多路I/O復用技術大致使用場景為:構造一張感興趣的文件描述符列表,然後調用多路復用的IO接口,在接口中進行阻塞,直到這些描述符中的一個已準備好進行I/O時

android ANR、traces檔案獲取例項分析

前言:前段時間專案開發中遇到anr的問題,時間緊急,一時間又難以定位,通過臨時方法解決後,最近有時間對ANR的問題做一次份細的解決方案,本文中的解決方案是通過綜合其他部落格後自己再通過例項驗證後得出的可行方案,讀者如遇類似問題可做參考,歡迎評論交流。

一文詳解大規模資料計算處理原理操作重點

摘要: 大資料技術主要針對的是大規模資料的計算處理問題,那麼要想解決的這一問題,首先要解決的就是大規模資料的儲存問題。 一、RAID技術 大資料技術主要針對的是大規模資料的計算處理問題,那麼要想解決的這一問題,首先要解決的就是大規模資料的儲存問題。大規模資料儲存要解決的核心問題有三個方面:

HashMap實現原理原始碼分析(轉載)

作者: dreamcatcher-cx 出處: <http://www.cnblogs.com/chengxiao/>        雜湊表(hash table)也叫散列表,是一種非常重要的資料結構,應用場景及其豐富,

Python使用Ctypes與C/C++ DLL檔案通訊過程介紹例項分析

專案中可能會經常用到第三方庫,主要是出於程式效率考慮和節約開發時間避免重複造輪子。無論第三方庫開源與否,程式語言是否與當前專案一致,我們最終的目的是在當前程式設計環境中呼叫庫中的方法並得到結果或者藉助庫中的模組實現某種功能。這個過程會牽涉到很多東西,本篇文章將簡要的介紹一下該過程的一些問題。 1.背景 多

springboot中使用Hystrix做超時處理示例問題分析

前言 此示例專案基於springboot 2.06 +hystrix 通過另一個專案在6543埠上開放一個介面,用於測試呼叫hystrix呼叫介面超時時候的處理策略。 具體實現 1. 開放介面 (此用於測試的介面我是在另一個springbo

併發程式設計(三)—— ReentrantLock實現原理原始碼分析

  ReentrantLock是Java併發包中提供的一個可重入的互斥鎖。ReentrantLock和synchronized在基本用法,行為語義上都是類似的,同樣都具有可重入性。只不過相比原生的Synchronized,ReentrantLock增加了一些高階的擴充套件功能,比如它可以實現公平鎖,同時也可以

網橋工作原理題目分析

<h2><center>網橋工作原理</center></h2> <h3>題目</h3> <h4>預備知識</h4> 1. 碰撞域(衝突域):在任意時刻,同一個衝突域中,只能有一臺機器在傳送資料,這個

HashMap、ConcurrentHashMap實現原理原始碼分析

HashMap:https://www.cnblogs.com/chengxiao/p/6059914.html ConcurrentHashMap:https://blog.csdn.net/dingjianmin/article/details/79776646   遺留問

ConcurrentHashMap JDK1.8中結構原理原始碼分析

注:本文根據網路和部分書籍整理基於JDK1.7書寫,如有雷同敬請諒解  歡迎指正文中的錯誤之處。 資料結構       ConcurrentHashMap 1.8 拋棄了Segment分段鎖機制,採用Node + CAS + Synchronized來保證併發安全進行實現

PageRank 演算法例項分析

本文一部分是針對圖的PageRank 的實現,以及具體資料集的分析過程的記錄。 另一部分是BFS的實現,並記錄每一層的節點數。 資料集下載地址  soc-Slashdot0811 、 roadNet-CA 、 soc-LiveJournal1 1. java 實現程式碼 M

【java基礎】ConcurrentHashMap實現原理原始碼分析

  ConcurrentHashMap是Java併發包中提供的一個執行緒安全且高效的HashMap實現(若對HashMap的實現原理還不甚瞭解,可參考我的另一篇文章),ConcurrentHashMap在併發程式設計的場景中使用頻率非常之高,本文就來分析下Concurre

HashMap實現原理原始碼分析

雜湊表(hash table)也叫散列表,是一種非常重要的資料結構,應用場景及其豐富,許多快取技術(比如memcached)的核心其實就是在記憶體中維護一張大的雜湊表,而HashMap的實現原理也常常出現在各類的面試題中,重要性可見一斑。本文會對java集合框架中的對

ConcurrentHashMap實現原理原始碼分析

ConcurrentHashMap是Java併發包中提供的一個執行緒安全且高效的HashMap實現(若對HashMap的實現原理還不甚瞭解,可參考我的另一篇文章),ConcurrentHashMap在併發程式設計的場景中使用頻率非常之高,本文就來分析下Concurrent

[轉]HashMap實現原理原始碼分析

目錄: 一、什麼是雜湊表 二、HashMap實現原理 三、為何HashMap的陣列長度一定是2的次冪? 四、為什麼重寫equals方法需同時重寫hashCode方法 一、什麼是雜湊表 雜湊表(hash table)也叫散列表,是一

WebService 工作原理例項教程

一、WebService到底是什麼? 先來看下標準的定義:Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統中傳遞過來的請求,輕量級的獨立的通訊技術。是:通過SOAP在Web上提