memória használat - címke

Java program memória használatának mérése

2023. november 2.2023. október 13. Szerző: Kaczur Sándor

Három különböző megközelítésben generálunk szövegeket és töltjük bele ezeket generikus listába. Olyan környezetet építünk, amely képes tesztelni/mérni a Java program/környezet memória használatát előtte/utána. A tárigény (memória, háttértár, feldolgozandó adatok mennyisége, adatforgalom) fontos eleme a hatékonyságnak. Gyakran előfordul, hogy a tárigényt csökkenteni kell egy program tervezése, implementációja vagy továbbfejlesztése során.

Feladat

A Java program előállít 100000 db 20 hosszúságú szöveget véletlen kiválasztott angol ábécé-beli betűkből. A szövegeket generikus listába tölti be. A program méri az általa felhasznált memória méretét/nagyságát úgy, hogy a műveletek előtti és utáni eredményekből különbséget számol. Egyszerű következtetéssel, becsléssel nagy mennyiségű adatra/memóriaterületre számíthatunk, így érdemes megabájt mértékegységet használni.

Közös konstansok

final int MIN_LIMIT=(int)'a';
97, a kis ‘a’ betű, a „legkisebb” generálható véletlen betű/karakter ASCII kódja
final int MAX_LIMIT=(int)'z';
122, hasonlóan a felső korlát
final int STRING_LENGTH_LIMIT=20;
a véletlenszerűen generálandó szövegek hossza
final int STRING_COUNT=1000000;
a véletlenszerűen generálandó szövegek száma, amik generikus listába kerülnek

Három különböző módszer

method1():
Az első módszer esetén String típusú szövegobjektumok keletkeznek úgy, hogy karakterenként kerülnek összefűzésre (konkatenáció) a += művelettel (operátorral). A véletlen karakterek sorszámaira int2char típuskényszerítés szükséges explicit módon (char). A vezérlés egymásba ágyazott ciklusokkal történik.
method2():
A második módszer esetén StringBuilder típusú szövegobjektumok keletkeznek. Szintén karakterenként generálva. Összefűzésüket az append() metódus végzi el. A típuskényszerítés és a vezérlés megegyezik az előző módszerrel.
method3() :
A harmadik módszer során a StringBuilder típusú szövegobjektumokból a Stream API beépített funkcionális műveletei állítják elő a generikus listát. A vezérlés egyetlen ciklusból áll.

Java forráskódok

Íme az első módszert megvalósító metódus. Futtatása 620 MB memóriát igényel:

private void method1() {

List<String> stringList=new ArrayList<>();

for(int i=1; i<=STRING_COUNT; i++) {

String generatedString="";

for(int j=1; j<=STRING_LENGTH_LIMIT; j++)

generatedString+=

(char)(int)(Math.random()*(MAX_LIMIT-MIN_LIMIT+1)+MIN_LIMIT);

stringList.add(generatedString);

}

//System.out.println(stringList);

}

Ez a második módszer metódusa, amely futása során 235 MB memóriát használ:

private void method2() {

List<String> stringList=new ArrayList<>();

for(int i=1; i<=STRING_COUNT; i++) {

StringBuilder generatedString=new StringBuilder();

for(int j=1; j<=STRING_LENGTH_LIMIT; j++)

generatedString.append(

(char)(int)(Math.random()*(MAX_LIMIT-MIN_LIMIT+1)+MIN_LIMIT));

stringList.add(generatedString.toString());

}

//System.out.println(stringList);

}

A harmadik módszer metódusa. 494 MB „memóriaterületbe kerül” lefuttatni:

private void method3() {

Random random=new Random();

List<String> stringList=new ArrayList<>();

for(int i=1; i<=STRING_COUNT; i++) {

String generatedString=random.ints(MIN_LIMIT, MAX_LIMIT+1)

.limit(STRING_LENGTH_LIMIT)

.collect(StringBuilder::new,

StringBuilder::appendCodePoint, StringBuilder::append)

.toString();

stringList.add(generatedString);

}

//System.out.println(stringList);

}

A metódusok hívása

private long getCurrentlyUsedMemory() {

long totalMemory=Runtime.getRuntime().totalMemory();

long freeMemory=Runtime.getRuntime().freeMemory();

System.gc();

return (totalMemory-freeMemory)/1048576;

}

void run() {

System.out.println("Felhasznált memória, adatok betöltése...");

System.out.println("1. teszt:");

long memoryStart=getCurrentlyUsedMemory();

System.out.println(" előtt: "+memoryStart+" MB");

method1();

long memoryStop=getCurrentlyUsedMemory();

System.out.println(" után: "+memoryStop+" MB");

System.out.println(" különbség: "+(memoryStop-memoryStart)+" MB");

//...

}

Eredmények

A tesztkörnyezet az alábbi eredményeket írta ki konzolosan:

Felhasznált memória, adatok betöltése...

1. teszt:

előtt: 2 MB

után: 622 MB

különbség: 620 MB

2. teszt:

előtt: 16 MB

után: 251 MB

különbség: 235 MB

3. teszt:

előtt: 17 MB

után: 511 MB

különbség: 494 MB

Más nézőpontok

Az is mérhető, hogy a program futása közben hány darab objektum keletkezik, melyik mennyi ideig „él”, melyik mennyi helyet foglal. Ez részletesebb képet nyújthat, összevetve a fenti globális helyfoglalással.
Figyelhető, hogy az automatikus szemétgyűjtő (Garbage Collector) milyen gyakran fut. Némileg befolyásolható, paraméterezhető a tevékenysége.
A forráskód bonyolultsága összefüggésben van annak karbantarthatóságával. Fontos lehet, hogy milyen könnyen dokumentálható, továbbfejleszthető.
A memóriafogyasztás szempontjából „túloptimalizált” program verzióváltás(ok) esetén több tesztelést, módosítást igényelhet. Ha egyáltalán valaki hozzá mer nyúlni. 😉
A memóriahasználat mérése során figyelembe kell venni, hogy a Java programon kívül Java futtatókörnyezet (JRE) is működik az operációs rendszeren, aminek szintén van erőforrásigénye.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Bemutattunk többféle módszert, illetve teszteredményeket. Részletes magyarázatot/indoklást most nem adunk a szakmai blogban. A Java SE szoftverfejlesztő tanfolyam szakmai moduljának 17-28. óra Objektumorientált programozás alkalmain természetesen széles körű áttekintést adunk a témakörrel kapcsolatosan, valamint más módszereket is bemutatunk. A hatékonyság klasszikus dimenziói: időigény, tárigény, bonyolultság. Több esettanulmányunk is van, amely egy-egy algoritmus lépésszámát méri, memória- és/vagy sávszélesség igényt mér, illetve elvi és/vagy koncepcionális bonyolultságot próbál meghatározni. Ezek közül többször redukálunk, csökkentünk tipikusan lépésszámot, memóriaigényt.

Galéria véletlen sorrendben

2023. november 2.2023. augusztus 11. Szerző: Kiss Balázs

Adott egy mappában lévő sok-sok képfájl, többféle formátumban, kiterjesztéssel. A feladat az, hogy időzítve jelenítsük meg ezeket a képeket véletlen sorrendben saját fejlesztésű Java program segítségével. A tervezés során áttekintünk többféle lehetőséget. Bemutatjuk a megoldáshoz szükséges lépéseket és a program működését.

A program tervezése

A szükséges bemeneti adatok

Egy mappa, abszolút vagy relatív útvonal, ahol a képfájlok megtalálhatók. A mappa átvehető a program paramétereként (ha parancssorban meghívva átadjuk) vagy lehet az aktuális mappa (ahonnan a programot jar fájlként elindítjuk). A program a mappában közvetlenül megtalálható képeket olvassa be. Az ott található almappákba nem megy bele.
A képfájlok különböző kiterjesztéseit tárolni kell. Többféle is lehet, így ehhez szükséges alkalmas adatszerkezet. A listában nem szereplő kiterjesztéssel rendelkező fájlok nem kerülnek feldolgozásra.
Érdemes a képfájlokat egy lépésben betölteni a memóriába. Így a program takarékos erőforrásként bánik a tárhellyel (merevlemez, pen-drive, SSD, hálózati meghajtó). Csak egyszer dolgozza fel (olvassa végig) a mappát. Feltételezzük, hogy a képfájlok beférnek a memóriába.
A program teljes képernyős, amiből elérhető a rendelkezésre álló terület mérete, ahol megjeleníthetők a képek. A program a betöltött képfájlok méreteihez is hozzáfér. Ez a méret kétféle lehet: bájtban kifejezhető a képfájl elfoglalt tárhelye, illetve pixelben kifejezhető a képfájl dimenziója (másképpen a megjelentéséhez szükséges terület mérete a képernyőn).

Hogyan működik a program?

Egyszerre egy kép jelenik meg. Időzítő befolyásolja a képfájlok közötti váltást. Meghatározza, hogy a képfájlok meddig látszanak (másképpen: eltelt idő, késleltetés, várakoztatás). A swing GUI-hoz tartozó időzítőt kell hozzá használni.
A program alkalmazkodik a képernyő, kijelző felbontásához, képarányához. A program végtelenítve működik, Alt + F4 billentyűkombinációval lehet kilépni belőle.
A képfájlok megjelenítésük során optimálisan, dinamikusan kitöltik a rendelkezésre álló téglalap alakú területet. A túl kicsi képeket nagyítani kell. A túl nagy képeket kicsinyíteni kell. Mindezt úgy, hogy a képarányt (aspect ratio) meg kell tartani, hogy a képek ne torzuljanak el. Az alábbi három példa balról-jobbra mutatja az optimális kitöltést, illetve azt a két esetet, ami akkor történik, amikor a kép méretéhez képest a megjelenítésre használható terület túl magas vagy túl széles:
A galériába tartozó képek közötti véletlen sorrendet meg kell oldani. A program a memóriába betöltött képek sorszámai alapján valósítja meg a véletlenszerű kiválasztást. A sorszámok összekeverednek. Egymás után nem jöhet ugyanaz a kép többször. Ha a képek „elfogynak”, akkor a program végtelenített működése szerint a képek sorszámai újra összekeverednek és „lejátszásra kerülnek”.

A program megvalósítása

A mappát a java.io csomag File osztályából létrehozott folder objektum tárolja (a "./" szövegliterál jelöli az aktuális mappát). A feldolgozandó képfájlok kiterjesztéseinek listáját egy dinamikus tömbből létrehozott generikus lista oldja meg: ArrayList<String> imageFileExtensionList=new ArrayList<>(Arrays.asList("JPG", "JPEG", "PNG", "GIF")). Egy képfájl memóriabeli tárolását a java.awt.image.BufferedImage típus valósítja meg, amelyekből szintén generikus lista épül: ArrayList<BufferedImage> imageList. A grafikus felhasználói felülethez tartozó javax.swing csomagbeli Timer osztály szükséges, például 2 mp-es várakoztatás és eseménykezelés: timer=new Timer(2000, (ActionEvent) -> { showRandomImage(); }). A GUI JFrame leszármazott keretobjektum. A grafikus felhasználói felület a teljes képernyőt elfoglalja: setExtendedState(MAXIMIZED_BOTH) és setUndecorated(true). A keretre egyetlen JLabel típusú, fekete hátterű lbImage objektum kerül, az alapértelmezett határmenti elrendezésmenedzser közepére (vízszintesen és függőlegesen egyaránt). A képfájlok sorszámai (a későbbi véletlen kiválasztáshoz) az imageIndexList generikus listába/kollekcióba kerülnek. Az index változó jelöli az aktuális, memóriába betöltött képfájl sorszámát, ami kezdetben nulláról indul.

A képfájlok betöltése az alábbiak szerinti:

private void createImageList() {

File[] imageArray=folder.listFiles((File path) -> {

String extension=path.getName().toUpperCase().

substring(path.getName().lastIndexOf(".")+1);

return imageFileExtensionList.contains(extension);

});

try {

for(int i=0; i<imageArray.length; i++) {

imageList.add(ImageIO.read(imageArray[i]));

imageIndexList.add(i);

}

Collections.shuffle(imageIndexList);

}

catch(IOException e) {

}

A fájlok kiterjesztésének szűrése a FileFilter interfész accept() metódusának megvalósításával történik. A fenti forráskódban mindez tömör, lambda kifejezéssel (művelettel) valósul meg. A fájlszűrőn az képfájl megy át, aminek a nagybetűssé alakított kiterjesztését tartalmazza az imageFileExtensionList kollekció. Az i-edik képfájl memóriába való betöltését az ImageIO osztály statikus read() függvénye oldja meg. A képfájlok sorszámainak véletlen összekeverése kezdetben megtörténik: Collections.shuffle(imageIndexList). A fájlkezelés miatt kötelező kivételkezelést most – itt a szakmai blogban – nem részletezzük.

Az időzítő eseménykezelése, a 2 másodpercenkénti képváltás így valósul meg:

private void showRandomImage() {

BufferedImage img=imageList.get(imageIndexList.get(index));

Dimension d=getScaledDimension(new Dimension(

img.getWidth(), img.getHeight()), lbImage.getSize());

ImageIcon imageIcon=new ImageIcon(img.getScaledInstance(

(int)d.getWidth(), (int)d.getHeight(), Image.SCALE_SMOOTH));

lbImage.setIcon(imageIcon);

index++;

if(index==imageIndexList.size()) {

Collections.shuffle(imageIndexList);

index=0;

}

A program alábbi metódusa felel a képarányhoz kötődő műveletekért:

private Dimension getScaledDimension(

Dimension imageSize, Dimension area) {

double widthRatio=area.getWidth()/imageSize.getWidth();

double heightRatio=area.getHeight()/imageSize.getHeight();

double ratio=Math.min(widthRatio, heightRatio);

return new Dimension((int)(imageSize.width*ratio),

(int)(imageSize.height*ratio));

}

A program tesztelése

Érdemes lehet tesztelni nem ajánlott (rossz) megoldásként azt, hogy a program az időzítőnek megfelelően, dinamikusan olvasná be a képfájlokat, amivel lényegesen kevesebb memóriát igényelne.
Van-e reális korlát arra, hogy mennyi, mekkora képek „férnek el” a memóriában?
Hogyan befolyásolja a képfájlok száma és az általuk elfoglalt tárhely a program indulását?
Mi történik, ha nincs megfelelő kiterjesztésű képfájl a mappában? És ha több 1000 kép van benne?
Hogyan jelennek meg (megjelennek-e) az animációt tartalmazó képfájlok? Például a GIF képformátum nem csak statikus egyetlen képet tartalmazhat, hanem lehet animált is.
Teljesen megvalósul-e a reszponzivitás? Ha igen, mi indokolja? Ha nem, miért nem és hogyan lehetne megoldani?

Ha átmenetileg kikapcsoljuk a teljes képernyős megjelenítést, akkor könnyen tesztelhetővé válik a megvalósuló reszponzivitás. Másképpen a program dinamikusan alkalmazkodik a rendelkezésre álló (rajzolható) terület méreteihez (szélesség és magasság):

A program továbbfejlesztési lehetőségei

A program rekurzívan bejárhatná a folder által megjegyzett útvonalból kiindulva a teljes (al)mappaszerkezetet.
A program paraméterezhető lehetne a képfájlok kiterjesztéseivel. Akár konfigurációs fájlból is beolvashatná az imageFileExtensionList adatszerkezetet, például XML, JSON formátumban is.
A program ellenőrizhetné, hogy a mappában lévő összes kép befér-e a memóriába. A program kezelhetne ehhez kötődően többféle limitet: például az első 100 db képet töltené be, és/vagy csak annyi képet tölt be, ami belefér például 64 MB-ba.
A program mutathatná folyamatindikátorral induláskor a képfájlok betöltését. Vagy betölthetné például az első 5 db-ot és háttérszálon a többit, amíg az első 5-öt „lejátssza”.
Ha például a program 10 képet tölt be mappában lévő képfájlokból, akkor ezek 0-tól 9-ig sorszámozódnak. A sorszámok összekeverve következnek. Ha az első menetben az utolsó kép sorszáma például a 7 volt, akkor a következő ismétlődő menet nem kezdődhetne 7-tel.
A programból ki lehetne lépni az Esc billentyűvel is. KeyListener interfésszel megoldható.
A program kezelhetne egyéb képfájlformátumokat is: például animált GIF, statikus WebP, animált WebP.
A program könnyen kiegészíthető prezentációk diáinak időzített/felülbírált megjelenítésére.
A program által beolvasott képfájlokból generálható PDF fájl is (rácsos sablonnal, például 6 db kép laponként). A feldolgoztt mappában lévő képfájlok könnyen feltölthetők FTP szerver adott mappájába, átméretezhetőek csoportosan, elküldhetők nyomtatási sorba is.
Érdemes megismerni a JDK-n kívüli egyéb, képfájlokat kezelő osztályok, csomagok funkcióit, például: OpenIMAJ, TwelveMonkeys ImageIO.
A swing-es felület kiegészíthető mappatallózással, egyéni fájl(típus)szűrőkkel, paraméterezhető lehet a véletlenszerű kiválasztás algoritmusa, változtatható az időzítés késleltetése.
Mivel a program teljes képernyős, így elrejthető az egérmutató.
A képek „lejátszásából” lehetne generálni animált GIF-et.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb animációs, szimulációs programot tervezni, kódolni, tesztelni.

Egy példányban futó Java program

2023. november 2.2022. január 17. Szerző: Kaczur Sándor

Gyakran észrevesszük, hogy a programok futtatásakor vannak bizonyos korlátok. Például egyszerre általában csak egyetlen telepítőprogram futhat egy operációs rendszeren. Vagy amíg fut egy program korábbi verziójának eltávolítása, addig nem futhat a program új verziójának telepítője. Vagy egy nagyobb erőforrás igényű program (periféria meghajtó program, képernyő videó+hang rögzítő, hardveres gyorsítást használó játékprogram) egyszerre csak egy példányban indítható el. Előfordulhat kategóriánkénti korlát is, például a különböző víruskereső programok általában „nem tűrik meg” egymást, kizárólagosságot „követelnek”.

Lássunk példát arra, hogyan kell készíteni egy példányban futó Java programot!

Néhány dolgot át kell gondolni:

Amikor először indítjuk el a programot, akkor olyan egyedi dolgot kell beállítani, ami mindvégig úgy marad, amíg a program fut. Ezt megtehetjük a memóriában, de megfelelő jogosultsággal futtatva a programot akár beleírhatunk a Windows rendszerleíró adatbázisába (Registry) is. Előbbi módszer platformfüggetlen lenne – ahogyan egy Java programhoz illik –, és az utóbbi megoldás pedig operációs rendszertől függne.
Amikor többedszer (második, harmadik… példányban) indítjuk el a programot, akkor ezt az egyedi dolgot észlelni kell és meg kell akadályozni a program másodszori, harmadszori elindítását. Hasznos, ha ezekben az esetekben kapunk hibaüzenetet, például: „This application is already running”.
Amikor a programot szabályosan állítjuk le, akkor a korábban beállított egyedi dolgot semmissé kell tenni. Ez biztosítja, hogy a program egymás után – egymással nem párhuzamosan, egymástól függetlenül – elindítható lesz.

A megoldás két részből áll. Ez a Java forráskód első része:

private static ServerSocket ss=null;

static {

try {

ss=new ServerSocket(65001, 10, InetAddress.getLocalHost());

}

catch(UnknownHostException e) {

;

}

catch(IOException e) {

JOptionPane.showMessageDialog(null,

"This application is already running.",

PROGRAM_STUDENT_TITLE, JOptionPane.ERROR_MESSAGE);

System.exit(0);

}

A program indulásakor le kell futni a fenti forráskódnak. A static blokk a konstruktor előtt hajtódik végre (például a modell vagy a nézet rétegben). A java.net csomag kötetlen ServerSocket osztályú ss nevű objektumát kell inicializálni helyben ( InetAddress.getLocalHost()) egy nem dedikált porttal ( 65001). Ez elsőre mindig sikerült és az objektum „beül a memóriába” egy nem blokkoló elven működő háttérszálon. Ha (többedszerre) nem sikerül létrehozni az objektumot, akkor – kezelve a kötelezően kezelendő kivételeket – hasznos jelezni ezt logban, konzolon vagy felbukkanó párbeszédablakban és a programból ki kell lépni (másképpen: a duplikált futtatását meg kell akadályozni).

Ez a Java forráskód második része:

try { //a program csak 1 példányban futhat

if(ss!=null && !ss.isClosed())

ss.close();

System.exit(0);

}

catch(IOException e) {

;

}

A programból való szabályos kilépéskor le kell futni a fenti forráskódnak. Ez ellenőrzést követően lezárja az ss objektumot és kilép a programból. Például a main() metódusban, ha elfogynak az utasítások egy konzolos alkalmazásban, vagy GUI-s programban nyomógombra kattintás actionPerformed() esemény, vagy (fő)ablak bezárásának kísérlete WindowClosing() esemény.

A programot érdemes körültekintően tesztelni. Ha elrontjuk a fenti felsorolásban vázolt logikai működés végrehajtásának sorrendjét, akkor fejlesztés vagy tesztelés közben akár a számítógépet is újra kell indítanunk.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal megismerjük a megoldás elméleti hátterét és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal többféle megvalósítást is kódolunk, tesztelünk.