Jeg er midt i en debugsession i en Java applikation som nægter at virke. Maskinen er en 64bit server med 16 fysiske CPU'er. Efter et par timer går det op for mig at Java’s threadlocal er årsagen. Applikationen køre fint på en dual core maskine hvor CPU’er har fælles hukommelse men kan ikke køre på en maskine hvor alle CPU’er har hver deres hukommelse. Jeg går ud fra at det underliggende operativsystem skifter CPU hvorefter min Java proces mister sin kontekst. ThreadLocal er en slags global variable allokeret til en tråd på en måde så den er synlig for alle objekter der eksekveres i denne i denne tråd. Denne metode benyttes ofte til at binde fx bruger-id eller transaction-id til en tråd og i meget sjældent tilfælde en database forbindelse. I dette tilfælde er det det sidste. Hvis man kigger ind i threadlocal klassen finder man en nøgle med værdien 0x61c88647 og alle nye objekter af denne type tildeles værdien hash_increment plus værdien 0x61c88647. Altså, værdien 0x61c88647 er jo et tal i 16tals formatet og hvis man omsætter det til et decimaltal får man enten 2654435769 eller -1640531527. Det er en 32-bit signed version af den usignerede 2654435769 og er den faktiske værdi som Java bruger til at beregne hash. Tallet repræsenterer ”The Golden Section” eller den gyldne ratio(sqrt (5) -1) gange to til potensen af 31. Check Dr Ron Knott algoritmer og Donald Knuth, de bøger hører hjemme hos en enhver seriøs programmør. Måske også Merck Manual ”adorns your health practitioner's”. Koden for threadlocal en smule kompliceret og jeg må ty til Dr Heinz for en forklaring. Tanken bag tidligere versioner af Java threadlocals var at dele state mellem flere tråde hvilket gør dem praktisk talt ubrugelige for multi-core-applikationer. I Java 1.4, blev et nyt design introduceret hvori threadlocals blev opbevaret direkte i den eksekverede tråd. Når man kalder metoden get() sker det på tråden og der returneres en instans af threadlocalmap som er en slags indre klasse af threadlocal. I teorien skulle en udgående tråd fjerne sine threadlocal værdier lige før garbage collection kaldes med exit() metoden. Hvis vi derimod glemme at fjerne en threadlocal er den stadig berettiget til automatisk garbage collection. Det skyldes en weak references intern i threadlocal til threadlocalmap der har normalt stærke henvisninger til værdier. Et threadlocal objekt bliver garbage collected når den eksekverede tråd dør. Undtagen hvis tråden er blevet trukket ud af en objekt pool som fx i nogle applikationsserverer, i disse tilfælde bliver værdierne aldrig garbage collected. Når et threadlocal objekt bliver garbage collected bliver den svage reference threadlocalmap ryddet. Hvornår bliver det så virkeligt slettet fra threadlocalmap. Når vi kalder get() metoden på en indgang i java.util.WeakHashMap fjernes alle gamle indgange. Hvis vi kalder get() på threadlocalmap går det hurtigere men kan give forældet poster og dermed memory leaks. Når man kalder ThreadLocal set() kan det falde ind under disse kategorier: # hvis værdi ikke findes indsættes den. # hvis vi finder vores nøgle, byttes den med ny værdi. # hvis der ikke er plads til flere værdier. Denne fase bruger en O(log2n) algoritmen i første omgang. # hvis en nøglen er fjernet så er posten slettet. Hvis du ønsker flere oplysninger om, hvordan det virker, kan du få nogle ideer fra Knuth 6.4 AlgoritmeR. Best Practices hvis du absolut vil bruge threadlocals skal du sørge for at fjerne de indsatte værdier når du er færdig med dem, og helst inden du afleverer din tråd til en tråd pool. Den bedste måde at gøre dette på er at bruge metoden remove() i stedet for set(null) som vil medføre at weak reference mappe bliver fjernes straks sammen med værdien. 2008-11-17T22:19:08Z 126 126 true 48 2008-11-17T22:21:13Z Jeg skal hastighedsoptimere en Java applikation. Den skal performe max på kortest mulige tid. Den kan ikke skalere udad som man normalt ville ønske men kun opad. Det vil sige en enkelt supermaskine med 16 CPU'er og 16G ram i 64bit software. I de senere år er kravet om hurtigere CPU hastigheder er faldet mens kravet om antal CPU'er er steget. Grunden er at en hurtig processor bruger mere strøm end to processorer på den samme kraft og man udnytter altså forholdet mellem ydeevne og forbrug. Problemet med at skalere en Java applikation er først og fremmest at Java ikke kan udnytte en ægte multicore arkitektur så den ønskede effektivitet kan opnås. Man kan tilføre så mange CPU'er man vil men Java kan ikke udnytte dem. Dog kan man sige at sige at Java processerne får mere frihed idet de andre processer på maskinen som fx databaser kan køre på andre cores. Selve Java applikationen er en heterogen monolitisk struktur og den skal eksekveres som en 32bit applikation. Det vil sige at den kun kan udnytte 2G hukommelse eller mindre. Det betyder desværre også at man skalere på den laveste fællesnævner. Men hvad sker der når man flytter en applikation fra en dual core maskine til en ægte fysisk 16 core maskine? Min interesse i sagen er kun henvendt på i hvilken udtrækning Java kan udnytte de mange processorer. Hvis Java kun kan udnytte en processor må applikationen kunne køre på samme vis som på andre duals maskiner. Hvad ville der ske hvis Java kunne udnytte flere CPU’er og de enkelte processer udsættes for ægte samtidighed, altså potentielt mange samtidige eksekvererne tråde i samme objekt? To ting vakte min opmærksomhed. Dels en memory leak og dels en slags forvirring omkring konfiguration og resourcer som fx databaseforbindelser. Memory leaks i applikationen skyldes bla ikke frigjorte værdier fra hukommelsen. Den andre adfærd var mere underlig. Applikationen kunne køre skiftevis langt før en tilstand reageret på manglede resourcer. Til min store overraskelses opdager jeg efter flere timers debug session at problemet ligger i ThreadLocal objektet i Java eller rettere dem måde man bruger dem på. Applikations designeren binder databaseforbindelser i disse tråd relaterede objekter. Når en container tråd dør tager den de lokale objekter med sig. Men når 64bit maskinen bestemmes sig for at skifte CPU mister alle threadlocals konteksts. Det betyder at konfiguration og resources bliver frigivet midt i kørselen. ThreadLocal har været en meget brugt strategi gennem mange år og benyttes til at bære fx et ID gennem en applikation både i en tråd men jeg vil påstå at det er et antipattern at benytte den til andet fx databaseforbindelser. læs: Thread-local storage Efter udbedrelse af problemerne køre softwaren fint på 64bit maskinen. Java installationen bruger to, måske tre CPU'er til at eksekvere Java softwaren. Når man skalere er det ønskeligt at kunne skalere lineært, altså ved en fordobling af kraft forøger man hastighed gange to. Reelt set køre denne Java applikation på en af de 16 hurtige CPU ad gange og udnyttelsen af den fine hardware stinker max. Hvis man vil kunne skalere sine applikationer må man skrive dem til multicore. "Small Things, Loosely Joined, Written Fast":posts/122-Small-Things-Loosely-Joined-Written-Fast 2008-11-01T09:51:34Z 124 124 true 48 2008-11-02T22:50:31Z