Én, ha neked volnék, a 'disposed' ablak mutatóját (mutatóit) kézileg null-ra állítanám, hogy ezzel is bátorítsam a garbage collectort arra, hogy felszabadítsa a hozzá tartozó memóriát.
Ok, ez igaz. De a következőt nem értem: -létrehozom az internalFrame-et -hozzáadom a desktophoz -bezárom (defaultCloseOperation = dispose) -meghívom a System.runFinalization() -t és a System.gc()-t Ha ezután a bezárt myInFrame pack() és setVisible(true) metódusait meghívom, majd újra hozzáadom a desktophoz, megjelenik az ablak. Biztosan én értek valamit félre, csak nem tudom mit. A myInFrame csak egy textArea-t tartalmaz, hogy legyen rajta valami. Semmilyen extra eseménykezelő nincs, szóval nem értem miért nem szabadul fel.
A gc() metódus arra való, hogy rávegye a szemétgyűjtő mechanizmust a már finalizált objektumok által lefoglalt memória felszabadítására. Azokat az objektumokat, melyekre nincs már hivatkozás, tehát a szemétgyűjtő mechanizmusra várakoznak, de még nem derítette fel azokat a szemétgyűjtő mechanizmus, mert még a finalize() metódusuk nem futott le, a gc() nem fogja kitakarítani. A gc() hívás előtt kell egy runFinalization() hívás, amivel ráveszed a szemétgyűjtő mechanizmust, hogy hívja meg azokat a finalize() metódusokat, melyek olyan objektumok destruktorai, melyekre már nincs hivatkozás, hogy ezután majd a gc() hívással felszabadíthasd az ezek által lefoglalt memóriát. Tehát először runFinalization(), majd gc(). Bővebben: System.runFinalization()
Egy kis segítség kellene: egy MDI programot farigcsálok, a gondom az hogy ha létrehozok egy InternalFrame-et, hozzáadom a desktopPane-hez, majd az internalFrame-et dispose-zal megszüntetem, a rá mutató referencia nem lesz null. Készítettem rá egy tesztprogramot, ami semmi mást nem csinál csak ablakokat nyitogathatok és zárhatok be, ugyan az a helyzet. Guglizással elég ellentmondó válaszokat kaptam, van aki szerint ez normális. Ha az, hogyan érhetem el hogy tudjam, egy ablak be lett zárva, és csak akkor hozhassam létre újra? Ha dispose() után az ablak ugyan úgy létezik (azaz az általa használt erőforrásokat a gc nem szabadítja fel, hiszen a referencia .toString metódusa működik), akkor pár kinyitás-becsukás után lassan elfogy a memória?
Szerintem meg amig az ember egy RISC/CISC processzorra ir programot addig jo ha legalabb nagy vonalakban tisztaban van azzal, hogy amit beir HLL utasitast abbol mi lesz LL szinten. Kulonben az ember soha nem fogja megerteni a programnyelvek kozti kulonbsegeknek okait, illetve hogy mitol alakul egy nyelv ugy ahogy.
Pl. a most bekerulo Closure-k ki lettek hagyva a lexikal scoping adta nehezsegek miatt, C-ben sincsenek, ellenben Pascalban vannak.
Szerintem ez mindig "elojon". Minden HLL utasitasbol a vegen vhol gepi kod szuletik es fut le. En pl. HLL nyelvekkel kezdtem majd kesobb pont azert kezdtem el foglalkozni assemblyvel (csak elmeleti szinten), hogy jobban megertsem milyen kovetkezmenyei vannak/lehetnek egy egy HLL megoldasnak.
Hat en azt gondoltam, hogy minel "High-abb" annal kevesbe. C eseteben, meg azon csodalkoznek, ha lenne olyan, hogy String. Java-nal mar azon, ha nem lenne olyan, hogy String. C-nel azert fejben meg sokszor "leforditottam" magamban a kodot assemblybe ropteben. Java-nal mar ez meg sem fordul persze a fejemben, mar nem "gondolok utana". Nyilvan ez igy van jol. Persze ilyen esetekben(szalak), az ember kicsit "lejjebb ereszkedik".
Ok, hibasan fogalmaztam, mindegyik tesztben az atomic volt gyorsabb, de az 1000%-os arany miatt irtam, hogy nem sikerult eloideznem a "vart kulonbseget". Az emlitett konyv eseteben ez 40%. En pedig az egymagos linuxos rendszert vettem etalonnak, nem pedig a 8 "magos" windows-ost.
Ha nem irok ide ilyen csacskasagokat, nem szuletnek ilyen "nemileg" tartalmasabb hozzaszolasok sem, mint amilyet irtal, es akkor mi lenne ezzel a topic-kal? :)
Nem irsz csacskasagokat azzal ha kerdezel vmit, foleg ha olyat amit korabban nem kerdeztek. Nekem a Java performance illetve multithreading a "szakteruletem", vagyis ez kifejezetten erdekel, viszonylag melyebb a tudasom ezen a teruleten mint az atlagnak. Egyebkent is szivesen fordulok masokhoz segitsegert amikor vmit nem tudok (ilyen sokszor van).
(( cmpxchg: Nagyon regen - gepi kodu, majd assembly programozas utan, meg amikor c-ben irogattam ezt-azt - gondoltam utoljara arra, hogy milyen assembly kodra fordulhat a program, erdekes, hogy ez meg a Javanal is elojon egyeseknek. :D ))
Szerintem ez mindig "elojon". Minden HLL utasitasbol a vegen vhol gepi kod szuletik es fut le. En pl. HLL nyelvekkel kezdtem majd kesobb pont azert kezdtem el foglalkozni assemblyvel (csak elmeleti szinten), hogy jobban megertsem milyen kovetkezmenyei vannak/lehetnek egy egy HLL megoldasnak.
A prog celja, a monitoros es az atomic-os szalszinkronizacio sebessegenek osszehasonlitasa. Elvart eredmenye pedig az atomicos gyorsabb volta. Ezt ugyebar nem sikerult eloideznem, lasd linuxos ertekek.
Szerintem meg jol latszik, az atomic gyorsabb mint a monitorszinkron. Legalabbis nalam 2707ms << 25121ms. Majdnem 10x-es a kulonbseg.
Ha nem irok ide ilyen csacskasagokat, nem szuletnek ilyen "nemileg" tartalmasabb hozzaszolasok sem, mint amilyet irtal, es akkor mi lenne ezzel a topic-kal? :)
Egyebkent a kodot nem en krealtam, hanem az Utikalauzbol potyogtem be. A prog celja, a monitoros es az atomic-os szalszinkronizacio sebessegenek osszehasonlitasa. Elvart eredmenye pedig az atomicos gyorsabb volta. Ezt ugyebar nem sikerult eloideznem, lasd linuxos ertekek. Egyebkent tobbszori meres eredmenyet mutattam, es nem is atlagoltam, mert szinte azonos eredmenyek szulettek minden alkalommal. Azt gondolom egyebkent a Date tokeletesen megfelel a celra, nem ezen torzulnak az eredmenyek, ha torzulnak.
A tapasztalat persze mindenkeppen teged igazol, ugy tunik a kod nem nagyon alkalmas a ketfele szinkronizacio osszehasonlitasara.
(( cmpxchg: Nagyon regen - gepi kodu, majd assembly programozas utan, meg amikor c-ben irogattam ezt-azt - gondoltam utoljara arra, hogy milyen assembly kodra fordulhat a program, erdekes, hogy ez meg a Javanal is elojon egyeseknek. :D ))
Ezen a linken lathatsz egy kb. 1 oras eloaadast Kirk Pepperdine-tol java performance measurement teren nehany szorakoztato feladattal megspekelve, ha teljesitmeny teszteket szeretnel kesziteni szerintem mindenkepp erdemes megnezned.
Ez egy kicsit almat a kortevel valo hasonlitas. Az pl. legalabb olyan fontos lenne megemliteni, h melyik JVM-el vegezted el ezeket a teszteket. Tovabba ha tesztelsz, akkor legalabb 5x futtasd le ugyanazt a tesztet es az egyuttes eredmeny az tobbet mond mint egy egyszeri futas. Date helyett hasznalj vmi lightweightebb stoppert, egy sima System.currentTimeMillis is megteszi, de vannak kulon StopWatch classok is. A problema azzal amit csinaltal, hogy igy a Date objektum peldanyositasa is beleszamolodik a measurement-be.
A konkret eremenyekrol pedig te az elso ket verzioban egy Integert hasznalsz a harmadikban pedig AtomicIntegert ami oriasi kulonbseg.
Amikor beirod azt hogy ++Integer_variable, akkor hasznalod az autoboxing funkciot ami az 5-os javatol kerult bele, korabban erre nem lett volna lehetoseg. Az Integer egy immutable valtozo, azaz amikor beirod azt hogy ++Integer az a kovetkezot jelenti:
NewInteger.valueOf(OldInteger.intValue+1);
Ezt tovabb bontva, ha -128 es 127 kozotti az ertek akkor egy pointert kapsz egy mar inicalizalt Integerhez:
return IntegerArray(value)
ellenkezo esetben pedig:
return new Integer(value);
Azaz egy uj objektumot inicializalsz.
Ez osszessegeben annyit jelent, hogy az esetek egy elenyeszo reszetol eltekintve te a ++counter eseteben egy fuggvenyt hivsz meg, ami a heap-en foglal memoriat es minden esetben egy uj objektum konstrualasat eredmenyezi.
Ezzel szemben az AtomicInteger: ebben az esetben egyetlen egyszer epitesz objektumot utana marcsak a belso int valtozojat modositod. Ezt raadasul az UnSafe osztalyon keresztul teszi, ami lehetove teszi tobbek kozott a CAS (Compare And Swap) operaciokat amivel amolyan mikrotranzakciomenedzsment ill. atomicitas valosul meg. Az x86 procikon ez jellemzoen a cmpxchg operacio. Ez optimistic lock-ot tesz lehetove, azaz kimasolja az erteket eloszor egy regiszterbe, egy masikban eltarolja hozzaadva egyet, aztan ha nem valtozott az eredeti ertek akkor felulirja az erteket. Ha valtozott akkor ujra az egesz.
Az altalad beirt ertekek inkabb azt mutatjak, hogy tobbmagos kornyezetben jobban ervenyesul a multithreading, nagyobb az eselye annak hogy osszeakadnak a szalak mint egy singlecore-on szimulalt multithreading kornyezetben. Es akkor meg mindig nagyon sok fugg attol melyik JVM-et hasznaltad es az milyen optimizaciokat hajtott vegre.
Egyes ertekek (linuxnal a szinkronizacio nelkuli es az atomi muveletekkel vegzettek aranya) (masreszt a linuxos es win7-es gep megfelelo ertekeinek viszonya is) szamomra igen meglepoek.
package speed1;
import java.util.concurrent.atomic.*;
public class Main {
static Integer counter = new Integer(0); static class Updater extends Thread { Updater() { start(); } public void run() { for (int i = 0; i < 10000000; i++) { int cnt = ++counter; } } }
static Integer lockCounter = new Integer(0); static class LockUpdater extends Thread { LockUpdater() { start(); } public void run() { for (int i = 0; i < 10000000; i++) { synchronized (lockCounter) { int cnt = ++lockCounter; } } } }
static AtomicInteger atomicCounter = new AtomicInteger(0); static class AtomicUpdater extends Thread { AtomicUpdater() { start(); } public void run() { for (int i = 0; i < 10000000; i++) { int cnt = atomicCounter.getAndDecrement(); } } }
public static void main(String[] args) {
Thread[] threads = new Thread[20]; java.util.Date start = new java.util.Date(); for (int i = 0; i < threads.length; i++) { threads = new Updater(); } for (int i = 0; i < threads.length; i++) { try { threads.join(); } catch (InterruptedException e) { } } java.util.Date stop = new java.util.Date(); System.out.println(“Update: “ + (stop.getTime() - start.getTime()) + “ms”);
threads = new Thread[20]; start = new java.util.Date(); for (int i = 0; i < threads.length; i++) { threads = new LockUpdater(); } for (int i = 0; i < threads.length; i++) { try { threads.join(); } catch (InterruptedException e) { System.out.println(e.getMessage()); } } stop = new java.util.Date(); System.out.println(“LockUpdate: “ + (stop.getTime() - start.getTime()) + “ms”);
threads = new Thread[20]; start = new java.util.Date(); for (int i = 0; i < threads.length; i++) { threads = new AtomicUpdater(); } for (int i = 0; i < threads.length; i++) { try { threads.join(); } catch (InterruptedException e) { System.out.println(e.getMessage()); } } stop = new java.util.Date(); System.out.println(“AtomicUpdate: “ + (stop.getTime() - start.getTime()) + “ms”);
Az még hagyján, hogy offtopic, az még lehetne amiatt, hogy nem tudja bekategorizálni. De hogy benyomja vagy 5 topikba ugyanazt a szöveget 2 percen belül, az egy icipicit ütközik a netikettel akárhogyis nézem. Na mindegy.
Hobbi szinten fotózom, weblap szerkesztéshez / készítéshez nem értek – mégis belekerültem, próbálkozom vele. A program amit használok egy végtelen primitív, de számomra annál egyszerűbb, kezelhetőbb – „web page maker” – viszont eljutottam addig, hogy azt mondhassam, ez kevés nekem. Így kívül kerültem a program hatáskörén, próbálom egyéb külső segítséggel moddingolni, fejleszteni a honlapom…itt viszont már az én tapasztalatom bizonyult kevésnek – egyszerűen nem értek hozzá. (www.molnarbence.com)
A célom elvileg egyszerű. A képnézegetést, galériát szeretném lightbox szerűen megoldani, de 1 lightboxban nem egy képet megjelenítve, hanem egymás mellett sokat…ezt alapjaiban véve sikerült megoldani, egyetlen kivétellel, aminek a forrása is kissé más. A weblapomon van egy legördülő lista, aminek meg tudtam adni a célokat – ha kiválasztod őket, hova ugorjon. S ezt is ugyan olyan lightbox szerűen szeretném kivitelezni, akár csak a többi (sport, koncert, egyéb, kapcsolat) kategóriát. Ha most kiválasztasz egyet a legördülő közül, láthatod, hogy hogyan működik, egyszerűen egy másik oldalra dob át.
A web-oldal megjelenítő „lightbox” (lightwindow - http://www.p51labs.com/lightwindow) működése:
- megadottfájlokat felmásolsz, - a html kódos weblapodba beillesztesz egy kódot head alá:
<div id="html1" style="position:absolute; overflow:hidden; left:77px; top:498px; width:200px; height:125px; z-index:7"> <script language="javascript"> function gotoUrl(url) { if (url == "") return; location.href = url; } function newWin(url) { // url of this function should have the format: "target,URL". if (url == "") return; window.open(url.substring(url.indexOf(",") + 1, url.length), url.substring(0, url.indexOf(","))); } function fnOnChange(){ gotoUrl(selector.options[selector.selectedIndex].value); return true; } var selector = (document.getElementById)? document.getElementsByName("formselect1")[0] : document.all.formselect1; selector.onchange=fnOnChange; </script></div>
Gondolom ebbe kellene valahogyan beleilleszteni a class="lightwindow" kódot, viszont nekem sehogy nem akart működni – minden esetben egész egyszerűen csak átdobott az oldalra…ötlet, vélemény, tanács? Segítségetek előre is köszönöm, Üdv, Bence :)
megerzesed telitalalat volt. (reszleteket nem irok, mert valszeg nincs itt a forumon olyan butuska, aki meg ebbol is tanulna)
hogy a linuxot nem erte el a windows kliens (ill elerte a tcpdump szerint, csak valszeg a callback nem ment) talan egy rossz hosts file okozta, de a megoldaldas a server inditasanal (tehat nem a kliensnel) a kovetkezo kapcsolo volt:-Djava.rmi.server.hostname=xxx.xxx.xxx.xxx volt, ahol xxx.xxx.xxx.xxx a server ip cime
.. mert jot rohogtem magamban, amikor az ismeros haver szivott a delphi-vel, amikor az egyik "gepen" muxik a progija a masikon meg nem. en meg gondoltam magamban, de jo, hogy eppen a javat tanulom.
(((persze azert a sajat butasagomban tovabbra is bizok)))
talan pont itt, az indexen duzzogott valamelyik forumozo, hogy az rmi egy kalap sz.r, meg a programozo sem tarthatja igazan a kezeben a rendszert, mert az sokat elrejt a hasznaloja elol. most meg mar en is elkeseredtem. dehat ez a cajo framework is az rmi folott van, nem? azzal sem leszek akkor elolrebb.
Juteszembe, ami elő szokott fordulni linuxon, hogy alapból felrak teljesen fiktív java disztribúciókat, szóval érdemes lenne azt ellenőrizned egy "java -version"-nel, hogy mi is fut akkor, amikor beírod azt, hogy java.
az az igazsag, hogy abban bizom, hogy valami orbitalis hulyeseget csinalok, es azert nem muxik a dolog linuxon, mert az nagyon elkeseritene, ha a dolgok a sajat termeszetuknel fogva nem mukodnenek ennyire. rament egy egesz szombatom, pedig abbol olyan keves van :(
