Re: [請益] java的效能!?

[HYL (@EVERYWHERE)]

※ 引述《sniffer (again)》之銘言：
: VM 本來就只是為了 portable, 至於到底是 JIT 還是 precompile 效果好,
: 這很不一定, 記憶體小的情況下, 甚至 interpreter 最好, FORTH 時代就有很多例子
: GC 把記憶體物件化, 其實很容易平行處理, 甚至專門有硬體來進行 GC,
: 所以 GC 在實做上可以視為幾乎沒有效能代價, 卻有重大方便,
: 唯一不方便的是 destructor 不確定何時會啟動, 讓寫 C++ 的人不習慣
: 要追求極致效能, 就要拋棄系統的記憶體管理, 自己配置一大塊來分,
: 大型的 C/C++ 程式多半都這麼做了

  寫了幾年的Java後，前陣子玩了幾個月的 Objective-C，才發現，GC果
  然是個邪惡的工具。

  用GC，免不了在某個時間點上，要把所有物件停下來，檢查一次所有物
  件後，才放行。問題就在於那個『某一個時間』點這問題，在Java中，
  這時間點不是我們能控制的。在 GUI程式上，變成跑GC時，UI反應就停
  下來，在 Server 程式上，變成所有處理中的事件都要停下來。這點，
  在用 Java 時，是怎麼調都無法避免的。

  在 iOS上， iOS支援 auto-release/gc，而回收物件的時間點， iOS是
  設在處理完一個 UI Event 後，這樣的好處是，使用者不容易查覺到
  auto-release pool在 處理時所造成的系統暫停。

  當然，各種處理方式，各有自己的生存空間應用範圍。除了是要拼系統
  資源、反應時間，要不然我還是偏好用 Java/Scala/Python來寫

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 114.42.14.68
→ sayya2311:java.lang.Runtime.gc();
→ Lordaeron:樓上的,你有看過文件嗎? 讀懂嗎?
推 sayya2311:為何有此問?
→ Lordaeron:請你看看就知囉.
→ sayya2311:什麼跟什麼?
→ sayya2311:http://www.java2s.com/Code/JavaAPI/java.lang/Runtime
→ sayya2311:gc.htm
→ james732:Runtime.gc(); 只是建議而沒有強制性
→ james732:並沒辦法真的控制『某一個時間』這個問題
→ choufeng:樓上正常. 調用gc() 只能"建議"VM這個時間可以作GC
→ choufeng:但實際上GC的時間點還是由VM自行決定
→ choufeng:第一行打錯 是"樓上正解" @@
推 dreambird:autorelease 不是 GC, OSX才有GC iOS沒有
→ Lordaeron:所以囉,有人不只會查不會看....
→ CCTSAI:手動GC最討厭的就是它常在你最不想要的時候GC來拖慢效能
→ CCTSAI:尤其是Android那種直接砍掉的GC法，一GC整台機器就頓一下
→ Lordaeron:你要auto回收,又不想付代價,有這麼好的事?
→ Lordaeron:想只拿錢不用打工的, 只有跟老媽要一途.
→ sayya2311:你們到底在high什麼? 當然只是建議? 在不需要GC的時侯
→ sayya2311:何必為了你的呼叫而去強迫GC? 但其它情況呢? 綽綽有餘..
→ sayya2311:demo的程式的網址都給上面了至少看一下吧? 在gc()與確認
→ sayya2311:空間被回收之間, 有任何sleep()的空檔嗎? 沒有...
→ iincho:我還以為我記錯, iOS記得是沒有GC的....
→ iincho:給樓上, 這邊討論的就是這種特殊情況....
→ sayya2311:不用擔心, 連呼叫GC也沒用的時侯, 接下來準備接
→ sayya2311:OutOfMemoryException就好了
→ iincho:不是沒用，這邊討論的主要是CG的時間點的問題。
→ iincho:你寫過Android上一些對responsiveness比較要求的東西就懂了
→ iincho:比如說Game，玩到一半系統給你GC一下玩得人會覺得畫面頓一
→ iincho:下，這種問題交給系統全動處理的時候就很討厭...
→ sayya2311:不過絕大部份GUI的問題, 都是GUI Thread的問題, 而不是
→ sayya2311:GC的問題, 因為類似問題不只發生在有VM的地方, 不過
→ sayya2311:沒看過程式的情況下原PO說GC我也只能說GC, 參考參考
→ choufeng:事實是文件自身都寫的很保守了 應該說叫用gc()是建議VM
→ choufeng:"趕快"作GC 但不能"保證"會去作GC
→ choufeng:不能依賴gc() 若記憶體消耗太多的情況下應該要對應的作法
→ choufeng:盡量讓物作能被reuse,不要用的物件盡量設為null等等
→ choufeng:省製造一點垃圾 而不是叫GC()沒用就等著接Exception
→ sayya2311:若不能插上一條RAM,等OutOfMemeory大概就是唯一能做的..
→ choufeng:有些小細節事實上會製造出很多垃圾 量小看不出來量大就知
→ choufeng:道可怕了 像是String接龍不改用StringBuffer等等的..
→ choufeng:nono~會出現OutOfMemeory沒什麼大不了的 是可以透過
→ choufeng:tunning來解決的 大部份情況是不需要走到加RAM
推 ledia:OutOfMemoryException ? 有寫過 Java 程式嗎? @@
→ Lordaeron:很多寫java 的稱為programmer 的想法就是,它會GC
→ Lordaeron:如果來不及而out of memory,就多買一點RAM,1G不夠買10G
→ Lordaeron:反正我的寫法就是這樣子,一切的問題都是Java 的錯.
→ choufeng:沒法~有時太多東西被包裝來,會讓人反而不懂背後的道理
→ Lordaeron:IBM的java 發生out of memory時,現在的並不一定會掉下來
→ choufeng:"一切的問題都是Java 的錯" 拷!這句我真的感同身受 我真
→ choufeng:的遇過降樣的人 真的讓我很無言...很瞎...
→ Lordaeron:只會log out of memory
→ sayya2311:不要做過多假設..假設自己還比能系統考慮得更多? 假設
→ sayya2311:程式還不夠完美? 假設loading只是定量? 也許你們還有更
→ sayya2311:多想像, 但再多假設也不會比"沒有任何假設"更真實.
→ Lordaeron:是啊, 所以GC了
推 bravomao:物件的存活週期短你可以用縮小young Gen的方式來處理，
→ bravomao:可以避過大規模的GC而且物件在Gen之間的轉移時間較少。
→ bravomao:當然大規模的GC遲早還是會到來，但是只要CPU處理能力夠，
→ bravomao:那大規模的GC(full gc)的影響就會小一點。
推 bravomao:IBM的VM很有趣，他沒有Perm區塊，native的HEAP也是用作業
→ bravomao:系統的，而且他在發生JAVA HEAP OOM的時候會自我處理，
→ bravomao:其實Sun的也會，大部分的VM再遭遇OOM的時候第一個動作好
→ bravomao:像都是去執行一次full gc，但是我遇過幾次IBM的VM在無法
→ bravomao:從full gc得到足夠的HEAP的時候他會自爆然後重啟....
→ bravomao:這樣算是全自動化吧......