java相關技術問答(二)
String爲何是final的
- 首先是爲了安全性,final表示不可變,不可被繼承,不能修改其方法保證安全
- 在多線程環境下,final類型的String保證線程安全
- String支持字符串常量池,相同字符串能夠指向相同地址
cas原理講下
- cas算法包含三個參數,v須要更新的變量,e預期值,n新的值
- 進入cas算法時,會先記錄更新變量值,而後進入compareAndSwap方法,判斷v是否等於e,相等說明v值沒有被改變,那v值更新成n值
線程池線程數配置多少合適?
- 須要根據所執行的任務類別來區分
- 分爲cpu密集型和IO密集型
- cpu密集型線程數和cpu數量相同
- io密集型,表示任務中須要執行像數據庫操做,磁盤操做這類io阻塞等待的操做
- 這個時候,有公式來算出最佳執行線程=(線程io阻塞時間/io運行時間+1)*cpu數
爲何redis單線程還這麼快
- redis雖然是單線程,但他的操做徹底是在內存進行的,內存的速度比IO快不少,能夠有效提升cpu的利用率
ThreadPoolExecutor中有哪些參數
- 核心線程數
- 最大線程數
- 最大空閒時間
- 單位
- 阻塞隊列
- 超出隊列任務處理
jdk7和jdk8特性
- jdk7可使用switch字符串了
- jdk7 try-catch資源塊,能夠自動釋放
- jdk8 lambda表達式 函數式編程
- jdk8 接口能夠實現默認方法了
防盜鏈方法
- 判斷請求頭refered,不是本身的域名,重定向到別的頁面
- 使用nginx,nginx能夠設置哪些域名能夠訪問哪些資源,其餘域名訪問都會跳到錯誤頁面
跨域問題解決方案
- 首先經常使用方法,添加請求頭head,能夠設置哪些域名容許跨域
- jsonp,前端技術,只支持get求情
- 使用網關,像nginx
- 使用httpClient轉一道,rpc調用
java中的隊列經常使用哪些
- ArrayBlockingQueue
- LinkedBlockingQueue
- DelayQueue
- PriorityBlockingQueue
Class.forName和classloader的區別
- Class.forName 只會加載類信息,不會執行類中的static塊
- classloader除了加載類,還會執行static塊
讓你優化系統,你會作哪些
- 首選若是條件容許,tomcat集羣部署,使用nginx作負載均衡和反向代理,分擔壓力
- 這可能會帶來問題,好比該tomcat應用不支持集羣部署,裏面存在定時任務,不容許重複執行,還有session共享問題等等。
- 因此在集羣前先解決上述問題,使用單獨的分佈式任務調度系統管理全部定時任務,系統代碼該優化的優化,接口須要保證冪等性
- 隨着集羣化,併發量qps確定能上來。接下來能夠併發執行的優化還有數據庫方面
- 開啓慢查詢,對用時比較長的語句進行explain,對該加索引的地方加上索引,能優化的地方優化。字段能用not null的地方用not null 由於is null的判斷可能引發索引失效
- group by默認會進行排序,若不須要使用order by null禁用排序
- 還有後端緩存也是一大塊,使用好緩存能夠減小大量數據庫io操做,能夠增大qps,可使用redis做爲緩存,
- 前端動靜分離,cdn加速
- 固然若是能有服務器操做權限,也能夠適當的進行JVM調優
Redis和Memcached總體對比
- redis在單核的性能上高於mecached,memcached能夠多核處理
- redis在單純key-value存儲上,memcached利用率更高,但redis使用hash結構的key-value則利用率比mecached高
- redis支持更豐富的數據操做,list,set,zset,string,hash
- redis可持久化數據
強引用,軟引用,弱引用,虛引用
- 強引用 最廣泛引用,對象引用存在永遠不會被垃圾收集器回收
- 軟引用和內存相關,軟引用對象內存不足時清除
- 弱引用,短期可取到對象,二次垃圾回收時清除
- 虛引用,假的引用,沒有實際引用對象。多用於檢測對象是否從內存中移除
hashMap在jdk1.7和1.8的區別
- 1.8在鏈表的基礎上加入了紅黑樹,當鏈表長度超過8,鏈表結構將變成紅黑樹模式,下降時間複雜度
- 但要使用這個優點,key必須時間比較接口compare
死鎖,活鎖和飢餓
- 死鎖,兩個以上線程競爭資源致使都得不到資源
- 活鎖,兩個線程互相謙讓資源致使都得不到資源
- 飢餓,一條線程一直等着另外一條線程一直持有資源
redis中穿透與雪崩的預防及解決
- 穿透,同一個不存在數據的請求屢次發起,因爲緩存找不到數據,每次會請求數據庫,致使緩存穿透
- 能夠經過緩存不存在的值,存入null值,訪問到時返回null值處理方法
- 雪崩,大量緩存在同一時間失效,請求都訪問數據庫
- 併發壓力經過加鎖或隊列,當緩存失效時,對某個key只容許一條線程訪問,其餘等待
- 緩存失效時間設置不一樣,儘可能均勻分佈
- 加二級緩存,二級緩存失效時間大於一級緩存能夠作到一級緩存失效,二級緩存能夠起到做用
- 若是能知道某個時間點會存在大量併發,能夠設計手動reload,從新加載緩存
ES和solr對比
- ES自帶分佈式不須要其餘依賴組件,solr須要依賴如zookeeper
- ES接近實時搜索,效率比solr高
- ES節點故障自動分配其餘節點
- 對已有數據進行搜索時,solr更快;實時創建索引,ES更快
給定a、b兩個文件,各存放50億個url,每一個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?
- 方案一
- 50億64字節大概在320G,明細所有加載內存不夠
- 首先的想法確定是分批對比,如何分,先a文件經過對每一個url hash(url)%1000 獲得的數表明文件編號,每一個文件大概300M
- 再b文件一樣的方式分割出相同數量1000個文件,則相同url所在的文件序號必定是相同的
- 由此能夠繼續對比每一對小文件,先將a1文件存入hashmap,再遍歷b1文件,在a1存在則是共同的url
- 方案二 若容許有必定偏差,可使用bloomfilter
- bloom filter 的4G內存能夠存儲340億bit
- 它的原理就是對存入值進行k散列,而後將數組中對應散列值置1
- 判斷值是否存在的方法就是散列後對應值都爲1,有一個爲0就是不存在。所有爲1則是很大可能存在
歡迎關注本站公眾號,獲取更多信息