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

看板Soft_Job作者 (@EVERYWHERE)時間14年前 (2011/05/24 20:27), 編輯推噓5(5推 0噓 61→)
留言66則, 9人參與, 最新討論串45/52 (看更多)
※ 引述《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
→
05/24 21:44, , 1F
java.lang.Runtime.gc();
05/24 21:44, 1F
→
05/24 22:01, , 2F
樓上的,你有看過文件嗎? 讀懂嗎?
05/24 22:01, 2F
推
05/24 22:09, , 3F
為何有此問?
05/24 22:09, 3F
→
05/24 22:12, , 4F
請你看看就知囉.
05/24 22:12, 4F
→
05/24 22:13, , 5F
什麼跟什麼?
05/24 22:13, 5F
→
05/24 22:15, , 7F
gc.htm
05/24 22:15, 7F
→
05/24 22:23, , 8F
Runtime.gc(); 只是建議而沒有強制性
05/24 22:23, 8F
→
05/24 22:24, , 9F
並沒辦法真的控制『某一個時間』這個問題
05/24 22:24, 9F
→
05/24 22:26, , 10F
樓上正常. 調用gc() 只能"建議"VM這個時間可以作GC
05/24 22:26, 10F
→
05/24 22:26, , 11F
但實際上GC的時間點還是由VM自行決定
05/24 22:26, 11F
→
05/24 22:27, , 12F
第一行打錯 是"樓上正解" @@
05/24 22:27, 12F
推
05/24 22:34, , 13F
autorelease 不是 GC, OSX才有GC iOS沒有
05/24 22:34, 13F
→
05/24 22:34, , 14F
所以囉,有人不只會查不會看....
05/24 22:34, 14F
→
05/24 22:35, , 15F
手動GC最討厭的就是它常在你最不想要的時候GC來拖慢效能
05/24 22:35, 15F
→
05/24 22:36, , 16F
尤其是Android那種直接砍掉的GC法，一GC整台機器就頓一下
05/24 22:36, 16F
→
05/24 22:55, , 17F
你要auto回收,又不想付代價,有這麼好的事?
05/24 22:55, 17F
→
05/24 22:59, , 18F
想只拿錢不用打工的, 只有跟老媽要一途.
05/24 22:59, 18F
→
05/24 23:06, , 19F
你們到底在high什麼? 當然只是建議? 在不需要GC的時侯
05/24 23:06, 19F
→
05/24 23:07, , 20F
何必為了你的呼叫而去強迫GC? 但其它情況呢? 綽綽有餘..
05/24 23:07, 20F
→
05/24 23:07, , 21F
demo的程式的網址都給上面了至少看一下吧? 在gc()與確認
05/24 23:07, 21F
→
05/24 23:08, , 22F
空間被回收之間, 有任何sleep()的空檔嗎? 沒有...
05/24 23:08, 22F
→
05/24 23:09, , 23F
我還以為我記錯, iOS記得是沒有GC的....
05/24 23:09, 23F
→
05/24 23:10, , 24F
給樓上, 這邊討論的就是這種特殊情況....
05/24 23:10, 24F
→
05/24 23:11, , 25F
不用擔心, 連呼叫GC也沒用的時侯, 接下來準備接
05/24 23:11, 25F
→
05/24 23:12, , 26F
OutOfMemoryException就好了
05/24 23:12, 26F
→
05/24 23:14, , 27F
不是沒用，這邊討論的主要是CG的時間點的問題。
05/24 23:14, 27F
→
05/24 23:14, , 28F
你寫過Android上一些對responsiveness比較要求的東西就懂了
05/24 23:14, 28F
→
05/24 23:15, , 29F
比如說Game，玩到一半系統給你GC一下玩得人會覺得畫面頓一
05/24 23:15, 29F
→
05/24 23:15, , 30F
下，這種問題交給系統全動處理的時候就很討厭...
05/24 23:15, 30F
→
05/24 23:22, , 31F
不過絕大部份GUI的問題, 都是GUI Thread的問題, 而不是
05/24 23:22, 31F
→
05/24 23:22, , 32F
GC的問題, 因為類似問題不只發生在有VM的地方, 不過
05/24 23:22, 32F
→
05/24 23:23, , 33F
沒看過程式的情況下原PO說GC我也只能說GC, 參考參考
05/24 23:23, 33F
→
05/24 23:29, , 34F
事實是文件自身都寫的很保守了 應該說叫用gc()是建議VM
05/24 23:29, 34F
→
05/24 23:29, , 35F
"趕快"作GC 但不能"保證"會去作GC
05/24 23:29, 35F
→
05/24 23:30, , 36F
不能依賴gc() 若記憶體消耗太多的情況下應該要對應的作法
05/24 23:30, 36F
→
05/24 23:32, , 37F
盡量讓物作能被reuse,不要用的物件盡量設為null等等
05/24 23:32, 37F
→
05/24 23:32, , 38F
省製造一點垃圾 而不是叫GC()沒用就等著接Exception
05/24 23:32, 38F
→
05/24 23:34, , 39F
若不能插上一條RAM,等OutOfMemeory大概就是唯一能做的..
05/24 23:34, 39F
→
05/24 23:34, , 40F
有些小細節事實上會製造出很多垃圾 量小看不出來量大就知
05/24 23:34, 40F
→
05/24 23:36, , 41F
道可怕了 像是String接龍不改用StringBuffer等等的..
05/24 23:36, 41F
→
05/24 23:37, , 42F
nono~會出現OutOfMemeory沒什麼大不了的 是可以透過
05/24 23:37, 42F
→
05/24 23:38, , 43F
tunning來解決的 大部份情況是不需要走到加RAM
05/24 23:38, 43F
推
05/24 23:39, , 44F
OutOfMemoryException ? 有寫過 Java 程式嗎? @@
05/24 23:39, 44F
→
05/24 23:41, , 45F
很多寫java 的稱為programmer 的想法就是,它會GC
05/24 23:41, 45F
→
05/24 23:42, , 46F
如果來不及而out of memory,就多買一點RAM,1G不夠買10G
05/24 23:42, 46F
→
05/24 23:42, , 47F
反正我的寫法就是這樣子,一切的問題都是Java 的錯.
05/24 23:42, 47F
→
05/24 23:43, , 48F
沒法~有時太多東西被包裝來,會讓人反而不懂背後的道理
05/24 23:43, 48F
→
05/24 23:43, , 49F
IBM的java 發生out of memory時,現在的並不一定會掉下來
05/24 23:43, 49F
→
05/24 23:44, , 50F
"一切的問題都是Java 的錯" 拷!這句我真的感同身受 我真
05/24 23:44, 50F
→
05/24 23:44, , 51F
的遇過降樣的人 真的讓我很無言...很瞎...
05/24 23:44, 51F
→
05/24 23:44, , 52F
只會log out of memory
05/24 23:44, 52F
→
05/25 00:01, , 53F
不要做過多假設..假設自己還比能系統考慮得更多? 假設
05/25 00:01, 53F
→
05/25 00:01, , 54F
程式還不夠完美? 假設loading只是定量? 也許你們還有更
05/25 00:01, 54F
→
05/25 00:02, , 55F
多想像, 但再多假設也不會比"沒有任何假設"更真實.
05/25 00:02, 55F
→
05/25 00:43, , 56F
是啊, 所以GC了
05/25 00:43, 56F
推
05/25 01:18, , 57F
物件的存活週期短你可以用縮小young Gen的方式來處理，
05/25 01:18, 57F
→
05/25 01:19, , 58F
可以避過大規模的GC而且物件在Gen之間的轉移時間較少。
05/25 01:19, 58F
→
05/25 01:20, , 59F
當然大規模的GC遲早還是會到來，但是只要CPU處理能力夠，
05/25 01:20, 59F
→
05/25 01:20, , 60F
那大規模的GC(full gc)的影響就會小一點。
05/25 01:20, 60F
推
05/25 01:22, , 61F
IBM的VM很有趣，他沒有Perm區塊，native的HEAP也是用作業
05/25 01:22, 61F
→
05/25 01:23, , 62F
系統的，而且他在發生JAVA HEAP OOM的時候會自我處理，
05/25 01:23, 62F
→
05/25 01:24, , 63F
其實Sun的也會，大部分的VM再遭遇OOM的時候第一個動作好
05/25 01:24, 63F
→
05/25 01:24, , 64F
像都是去執行一次full gc，但是我遇過幾次IBM的VM在無法
05/25 01:24, 64F
→
05/25 01:25, , 65F
從full gc得到足夠的HEAP的時候他會自爆然後重啟....
05/25 01:25, 65F
→
05/25 01:25, , 66F
這樣算是全自動化吧......
05/25 01:25, 66F
‣ 更多 HYL 的文章
文章代碼(AID): #1DswGqvv (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 45 之 52 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共52篇)
‣ 更多 HYL 的文章
文章代碼(AID): #1DswGqvv (Soft_Job)