java相關技術問答(二)

String爲何是final的

  1. 首先是爲了安全性,final表示不可變,不可被繼承,不能修改其方法保證安全
  2. 在多線程環境下,final類型的String保證線程安全
  3. String支持字符串常量池,相同字符串能夠指向相同地址

cas原理講下

  1. cas算法包含三個參數,v須要更新的變量,e預期值,n新的值
  2. 進入cas算法時,會先記錄更新變量值,而後進入compareAndSwap方法,判斷v是否等於e,相等說明v值沒有被改變,那v值更新成n值

線程池線程數配置多少合適?

  1. 須要根據所執行的任務類別來區分
  2. 分爲cpu密集型和IO密集型
  3. cpu密集型線程數和cpu數量相同
  4. io密集型,表示任務中須要執行像數據庫操做,磁盤操做這類io阻塞等待的操做
  5. 這個時候,有公式來算出最佳執行線程=(線程io阻塞時間/io運行時間+1)*cpu數

爲何redis單線程還這麼快

  1. redis雖然是單線程,但他的操做徹底是在內存進行的,內存的速度比IO快不少,能夠有效提升cpu的利用率

ThreadPoolExecutor中有哪些參數

  1. 核心線程數
  2. 最大線程數
  3. 最大空閒時間
  4. 單位
  5. 阻塞隊列
  6. 超出隊列任務處理

jdk7和jdk8特性

  1. jdk7可使用switch字符串了
  2. jdk7 try-catch資源塊,能夠自動釋放
  3. jdk8 lambda表達式 函數式編程
  4. jdk8 接口能夠實現默認方法了

防盜鏈方法

  1. 判斷請求頭refered,不是本身的域名,重定向到別的頁面
  2. 使用nginx,nginx能夠設置哪些域名能夠訪問哪些資源,其餘域名訪問都會跳到錯誤頁面

跨域問題解決方案

  1. 首先經常使用方法,添加請求頭head,能夠設置哪些域名容許跨域
  2. jsonp,前端技術,只支持get求情
  3. 使用網關,像nginx
  4. 使用httpClient轉一道,rpc調用

java中的隊列經常使用哪些

  1. ArrayBlockingQueue
  2. LinkedBlockingQueue
  3. DelayQueue
  4. PriorityBlockingQueue

Class.forName和classloader的區別

  1. Class.forName 只會加載類信息,不會執行類中的static塊
  2. classloader除了加載類,還會執行static塊

讓你優化系統,你會作哪些

  1. 首選若是條件容許,tomcat集羣部署,使用nginx作負載均衡和反向代理,分擔壓力
  2. 這可能會帶來問題,好比該tomcat應用不支持集羣部署,裏面存在定時任務,不容許重複執行,還有session共享問題等等。
  3. 因此在集羣前先解決上述問題,使用單獨的分佈式任務調度系統管理全部定時任務,系統代碼該優化的優化,接口須要保證冪等性
  4. 隨着集羣化,併發量qps確定能上來。接下來能夠併發執行的優化還有數據庫方面
  5. 開啓慢查詢,對用時比較長的語句進行explain,對該加索引的地方加上索引,能優化的地方優化。字段能用not null的地方用not null 由於is null的判斷可能引發索引失效
  6. group by默認會進行排序,若不須要使用order by null禁用排序
  7. 還有後端緩存也是一大塊,使用好緩存能夠減小大量數據庫io操做,能夠增大qps,可使用redis做爲緩存,
  8. 前端動靜分離,cdn加速
  9. 固然若是能有服務器操做權限,也能夠適當的進行JVM調優

Redis和Memcached總體對比

  1. redis在單核的性能上高於mecached,memcached能夠多核處理
  2. redis在單純key-value存儲上,memcached利用率更高,但redis使用hash結構的key-value則利用率比mecached高
  3. redis支持更豐富的數據操做,list,set,zset,string,hash
  4. redis可持久化數據

強引用,軟引用,弱引用,虛引用

  1. 強引用 最廣泛引用,對象引用存在永遠不會被垃圾收集器回收
  2. 軟引用和內存相關,軟引用對象內存不足時清除
  3. 弱引用,短期可取到對象,二次垃圾回收時清除
  4. 虛引用,假的引用,沒有實際引用對象。多用於檢測對象是否從內存中移除

hashMap在jdk1.7和1.8的區別

  1. 1.8在鏈表的基礎上加入了紅黑樹,當鏈表長度超過8,鏈表結構將變成紅黑樹模式,下降時間複雜度
  2. 但要使用這個優點,key必須時間比較接口compare

死鎖,活鎖和飢餓

  1. 死鎖,兩個以上線程競爭資源致使都得不到資源
  2. 活鎖,兩個線程互相謙讓資源致使都得不到資源
  3. 飢餓,一條線程一直等着另外一條線程一直持有資源

redis中穿透與雪崩的預防及解決

  1. 穿透,同一個不存在數據的請求屢次發起,因爲緩存找不到數據,每次會請求數據庫,致使緩存穿透
    • 能夠經過緩存不存在的值,存入null值,訪問到時返回null值處理方法
  2. 雪崩,大量緩存在同一時間失效,請求都訪問數據庫
    • 併發壓力經過加鎖或隊列,當緩存失效時,對某個key只容許一條線程訪問,其餘等待
    • 緩存失效時間設置不一樣,儘可能均勻分佈
    • 加二級緩存,二級緩存失效時間大於一級緩存能夠作到一級緩存失效,二級緩存能夠起到做用
    • 若是能知道某個時間點會存在大量併發,能夠設計手動reload,從新加載緩存

ES和solr對比

  1. ES自帶分佈式不須要其餘依賴組件,solr須要依賴如zookeeper
  2. ES接近實時搜索,效率比solr高
  3. ES節點故障自動分配其餘節點
  4. 對已有數據進行搜索時,solr更快;實時創建索引,ES更快

給定a、b兩個文件,各存放50億個url,每一個url各佔64字節,內存限制是4G,讓你找出a、b文件共同的url?

  1. 方案一
    1. 50億64字節大概在320G,明細所有加載內存不夠
    2. 首先的想法確定是分批對比,如何分,先a文件經過對每一個url hash(url)%1000 獲得的數表明文件編號,每一個文件大概300M
    3. 再b文件一樣的方式分割出相同數量1000個文件,則相同url所在的文件序號必定是相同的
    4. 由此能夠繼續對比每一對小文件,先將a1文件存入hashmap,再遍歷b1文件,在a1存在則是共同的url
  2. 方案二 若容許有必定偏差,可使用bloomfilter
    1. bloom filter 的4G內存能夠存儲340億bit
    2. 它的原理就是對存入值進行k散列,而後將數組中對應散列值置1
    3. 判斷值是否存在的方法就是散列後對應值都爲1,有一個爲0就是不存在。所有爲1則是很大可能存在
相關文章
相關標籤/搜索