JMH பெஞ்ச்மார்க்ஸில் நினைவகக் குவிப்பை திறம்பட நிர்வகித்தல்

ஜாவா பெஞ்ச்மார்க்ஸில் நினைவக சவால்களைப் புரிந்துகொள்வது

ஜாவாவில் தரப்படுத்தல் என்பது உங்கள் குறியீட்டின் செயல்திறன் நுணுக்கங்களை வெளிப்படுத்தும் ஒரு அறிவூட்டும் அனுபவமாக இருக்கும். இருப்பினும், மறு செய்கைகளுக்கு இடையே நினைவகக் குவிப்பு போன்ற எதிர்பாராத சிக்கல்கள், முடிவுகளை நம்பமுடியாததாக மாற்றும். 😓

ஜாவா மைக்ரோபென்ச்மார்க் ஹார்னஸ் (ஜேஎம்ஹெச்) போன்ற கருவிகளைப் பயன்படுத்தி, மறு செய்கைகள் முழுவதும் ஹீப் மெமரி பயன்பாடு படிப்படியாக அதிகரிப்பதை நீங்கள் கவனிக்கலாம். இந்த நடத்தை தவறான அளவீடுகளுக்கு வழிவகுக்கும், குறிப்பாக ஹீப் நினைவகத்தை சுயவிவரப்படுத்தும்போது. சிக்கல் அசாதாரணமானது அல்ல, ஆனால் இது வரையறைகளை சீர்குலைக்கும் வரை பெரும்பாலும் கவனிக்கப்படுவதில்லை.

இந்த நிஜ வாழ்க்கை சூழ்நிலையை கவனியுங்கள்: ஹீப் மெமரி உபயோகத்தை பகுப்பாய்வு செய்ய JMH வரையறைகளை இயக்குகிறீர்கள். ஒவ்வொரு வார்ம்அப் மற்றும் அளவீட்டு மறு செய்கைகள் அதிகரித்து வரும் அடிப்படை நினைவக தடம் காட்டுகிறது. இறுதி மறு செய்கையின் மூலம், பயன்படுத்தப்பட்ட குவியல் கணிசமாக வளர்ந்துள்ளது, இது முடிவுகளை பாதிக்கிறது. காரணத்தைக் கண்டறிவது சவாலானது, அதைத் தீர்க்க துல்லியமான படிகள் தேவை.

இந்த வழிகாட்டி JMH வரையறைகளில் இத்தகைய நினைவக சிக்கல்களைத் தணிப்பதற்கான நடைமுறை உத்திகளை ஆராய்கிறது. எடுத்துக்காட்டுகள் மற்றும் தீர்வுகளிலிருந்து வரைந்து, நினைவக பயன்பாட்டை உறுதிப்படுத்துவது மட்டுமல்லாமல் தரப்படுத்தல் துல்லியத்தையும் மேம்படுத்தும் நுண்ணறிவுகளை இது வழங்குகிறது. 🛠️ இந்தக் குறைபாடுகளை எவ்வாறு தவிர்ப்பது என்பதைக் கண்டறியவும், உங்கள் வரையறைகள் நம்பகமானவை என்பதை உறுதிப்படுத்தவும் காத்திருங்கள்.

JMH இல் நினைவகக் குவிப்பை நிவர்த்தி செய்வதற்கான பயனுள்ள நுட்பங்கள்

மேலே வழங்கப்பட்ட ஸ்கிரிப்ட்களில் ஒன்று பயன்படுத்துகிறது செயல்முறை பில்டர் தரப்படுத்தலுக்கான தனி JVM செயல்முறைகளைத் தொடங்க ஜாவாவில் வகுப்பு. ஒரு மறு செய்கையால் பயன்படுத்தப்படும் நினைவகம் அடுத்ததை பாதிக்காது என்பதை இந்த முறை உறுதி செய்கிறது. வெவ்வேறு JVM நிகழ்வுகளில் வரையறைகளை தனிமைப்படுத்துவதன் மூலம், ஒவ்வொரு மறு செய்கைக்கும் ஹீப் மெமரி நிலையை மீட்டமைக்கிறீர்கள். முந்தைய பயணங்களில் பயணிகளை ஏற்றிச் செல்லும் போது காரின் எரிபொருள் செயல்திறனை அளவிட முயற்சிப்பதை கற்பனை செய்து பாருங்கள். ProcessBuilder ஒவ்வொரு முறையும் காலியான காரில் தொடங்குவது போல் செயல்படுகிறது, மேலும் துல்லியமான வாசிப்புகளை அனுமதிக்கிறது. 🚗

மற்றொரு அணுகுமுறையைப் பயன்படுத்துகிறது System.gc() கட்டளை, குப்பை சேகரிப்பை செயல்படுத்த ஒரு சர்ச்சைக்குரிய மற்றும் பயனுள்ள வழி. இந்த கட்டளையை சிறுகுறிப்பு செய்யப்பட்ட முறையில் வைப்பதன் மூலம் @அமைவு(Level.Iteration), ஜேஎம்ஹெச் ஒவ்வொரு தரநிலை மறு செய்கைக்கு முன்பும் குப்பை சேகரிப்பை உறுதி செய்கிறது. இந்த அமைப்பானது, முந்தைய வேலைகளின் ஒழுங்கீனத்தைத் தவிர்ப்பதற்காக, பணிகளுக்கு இடையில் உங்கள் பணியிடத்தை சுத்தம் செய்வது போன்றது. System.gc() உடனடி குப்பை சேகரிப்புக்கு உத்தரவாதம் அளிக்கவில்லை என்றாலும், தரப்படுத்தல் சூழ்நிலைகளில், இது பெரும்பாலும் நினைவகத்தை குறைக்க உதவுகிறது, துல்லியமான செயல்திறன் அளவீடுகளுக்கு கட்டுப்படுத்தப்பட்ட சூழலை உருவாக்குகிறது.

போன்ற சிறுகுறிப்புகளின் பயன்பாடு @முட்கரண்டி, @வார்ம்அப், மற்றும் @அளவீடு JMH ஸ்கிரிப்ட்களில் தரப்படுத்தல் செயல்முறையின் மீது நுணுக்கமான கட்டுப்பாட்டை அனுமதிக்கிறது. எடுத்துக்காட்டாக, @Fork(மதிப்பு = 1, வார்ம்அப்கள் = 1) ஒரு வார்ம்அப் மறு செய்கையுடன் ஒரு போர்க்கை உறுதி செய்கிறது. இது பல முட்கரண்டிகளிலிருந்து எழக்கூடிய ஒட்டுமொத்த நினைவக சிக்கல்களைத் தடுக்கிறது. வார்ம்ப் மறு செய்கைகள் JVMஐ உண்மையான தரப்படுத்தலுக்குத் தயார்படுத்துகிறது, இது உகந்த செயல்திறனை உறுதி செய்வதற்காக வொர்க்அவுட்டிற்கு முன் வார்ம் அப் செய்வதோடு ஒப்பிடத்தக்கது. 🏋️‍♂️ இந்த உள்ளமைவுகள் JMHஐ நிலையான மற்றும் நம்பகமான வரையறைகளுக்கு ஒரு வலுவான கருவியாக மாற்றுகிறது.

இறுதியாக, யூனிட் சோதனை உதாரணம் நினைவக நடத்தையை எவ்வாறு சரிபார்க்கலாம் என்பதை நிரூபிக்கிறது. குறிப்பிட்ட செயல்பாடுகளுக்கு முன்னும் பின்னும் நினைவக பயன்பாட்டை ஒப்பிடுவதன் மூலம் Runtime.getRuntime(), எங்கள் குறியீட்டின் செயல்திறனில் நிலைத்தன்மையையும் நிலைத்தன்மையையும் உறுதிசெய்ய முடியும். எதிர்பாராத கட்டணங்கள் எதுவுமில்லை என்பதை உறுதிப்படுத்த, வாங்குவதற்கு முன்னும் பின்னும் உங்கள் வங்கிக் கணக்கு இருப்பைச் சரிபார்ப்பது போல் நினைத்துப் பாருங்கள். இத்தகைய சரிபார்ப்புகள் முரண்பாடுகளை முன்கூட்டியே கண்டறிவதற்கும், சுற்றுச்சூழலில் உங்கள் வரையறைகள் அர்த்தமுள்ளதாக இருப்பதை உறுதி செய்வதற்கும் முக்கியமானதாகும்.

import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
@Fork(value = 1, warmups = 1)
@State(Scope.Thread)
public class MemoryBenchmark {

    @Benchmark
    public int calculate() {
        // Simulating a computational task
        return (int) Math.pow(2, 16);
    }
}

import java.io.BufferedReader;
import java.io.InputStreamReader;

public class IsolatedBenchmark {

    public static void main(String[] args) {
        try {
            ProcessBuilder pb = new ProcessBuilder("java", "-jar", "benchmark.jar");
            pb.inheritIO();
            Process process = pb.start();
            process.waitFor();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;

@BenchmarkMode(Mode.Throughput)
@Warmup(iterations = 5)
@Measurement(iterations = 5)
@Fork(1)
@State(Scope.Thread)
public class ResetMemoryBenchmark {

    @Setup(Level.Iteration)
    public void cleanUp() {
        System.gc(); // Force garbage collection
    }

    @Benchmark
    public int compute() {
        return (int) Math.sqrt(1024);
    }
}

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

public class BenchmarkTests {

    @Test
    void testMemoryUsageConsistency() {
        long startMemory = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        int result = (int) Math.pow(2, 10);
        long endMemory = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
        assertTrue((endMemory - startMemory) < 1024, "Memory usage is inconsistent");
    }
}

நினைவக வளர்ச்சியை நிவர்த்தி செய்ய JMH பெஞ்ச்மார்க்குகளை மேம்படுத்துதல்

JMH அளவுகோல்களின் போது நினைவகக் குவிப்பு, பொருள் தக்கவைத்தல் மற்றும் வகுப்பு ஏற்றுதல் ஆகியவற்றால் பாதிக்கப்படலாம். மறு செய்கைகளின் போது ஜேவிஎம் பொருட்களை உருவாக்கும் போது, ​​இந்த பொருள்களின் குறிப்புகள் உடனடியாக அழிக்கப்படாமல் போகலாம், இது தொடர்ந்து நினைவகப் பயன்பாட்டிற்கு வழிவகுக்கும். பெரிய பொருள் வரைபடங்கள் அல்லது கவனக்குறைவாக குறிப்புகளை வைத்திருக்கும் நிலையான புலங்களைக் கொண்ட காட்சிகளில் இது அதிகரிக்கலாம். இதைத் தணிக்க, உங்கள் பெஞ்ச்மார்க் குறியீடு தேவையற்ற நிலையான குறிப்புகளைத் தவிர்க்கிறது மற்றும் பொருத்தமான இடங்களில் பலவீனமான குறிப்புகளைப் பயன்படுத்துகிறது. இத்தகைய நடைமுறைகள் குப்பை சேகரிப்பாளருக்கு பயன்படுத்தப்படாத பொருட்களை திறமையாக மீட்டெடுக்க உதவுகின்றன. 🔄

மற்றொரு அடிக்கடி கவனிக்கப்படாத அம்சம் நூல்-உள்ளூர் மாறிகளின் பங்கு. ThreadLocal வரையறைகளில் எளிதாக இருக்கும், ஆனால் ஒழுங்காக நிர்வகிக்கப்படாவிட்டால் நினைவகம் நீடித்திருக்கும். ஒவ்வொரு நூலும் அதன் சொந்த மாறிகளின் நகலை வைத்திருக்கிறது, அவை அழிக்கப்படாவிட்டால், நூலின் வாழ்க்கைச் சுழற்சி முடிந்த பின்னரும் தொடரலாம். பயன்படுத்தி மாறிகளை வெளிப்படையாக நீக்குவதன் மூலம் ThreadLocal.remove(), வரையறைகளின் போது திட்டமிடப்படாத நினைவகத் தக்கவைப்பை நீங்கள் குறைக்கலாம். இந்த அணுகுமுறை ஒரு மறு செய்கையால் பயன்படுத்தப்படும் நினைவகம் அடுத்தது தொடங்கும் முன் விடுவிக்கப்படுவதை உறுதி செய்கிறது.

இறுதியாக, வகுப்பு ஏற்றுதலை JVM எவ்வாறு கையாளுகிறது என்பதைக் கவனியுங்கள். அளவுகோல்களின் போது, ​​JMH மீண்டும் மீண்டும் வகுப்புகளை ஏற்றலாம், இது அதிகரித்த நிரந்தர தலைமுறை (அல்லது நவீன JVM களில் மெட்டாஸ்பேஸ்) தடயத்திற்கு வழிவகுக்கும். பயன்படுத்தி @முட்கரண்டி மறு செய்கைகளைத் தனிமைப்படுத்துவதற்கான சிறுகுறிப்பு அல்லது தனிப்பயன் வகுப்பு ஏற்றியைப் பயன்படுத்துவது இதை நிர்வகிக்க உதவும். இந்தப் படிகள் ஒவ்வொரு மறு செய்கைக்கும் ஒரு தூய்மையான கிளாஸ் ஏற்றுதல் சூழலை உருவாக்குகின்றன, இது JVM இன் இன்டர்னல்களின் கலைப்பொருட்களை விட இயக்க நேர செயல்திறனில் கவனம் செலுத்துவதை உறுதி செய்கிறது. இந்த நடைமுறையானது திட்டங்களுக்கு இடையில் ஒரு பணியிடத்தை சுத்தம் செய்வதை பிரதிபலிக்கிறது, ஒரு நேரத்தில் ஒரு பணியில் கவனம் செலுத்த உங்களை அனுமதிக்கிறது. 🧹