JBossWorld Boston, Jason T Greene, Zen of class loading
What is the Class class
– represents a class
– allocates memory on heap and permgen
– is referenced by every object instance of that class
– Unique (by name) only to a ClassLoader
– holds a reference to the ClassLoader
What is a ClassLoader
– responsible for loading classes
– holds strong reference to all classes it loads
– optional parent for delegation
Problem #1 – OutOfMemory:PermGen
– too many classes loaded
– sizing could be wrong, big application with many classes
– possible classloader leak
— hot deployment causes new classloader
— one instance to an object prevents garbage collection of all classes loaded by the classloader
Common leak sources
– static field on a class with a long lifecycle (on another classloader)
– caching frameworks
– persistent thread locals (automatic cleaning is *very* important)
– framework bugs (logging frameworks, third-party frameworks)
JDK class loading delegation
– parent-first prevents overriding a parent
– custom classloaders can do this (and they do!)
– bootstrap is searched even if parent==null
– bootstrap classes often return null for getClassLoader()
JDK has default hierarchy
– boot classpath (including lib/endorsed)
– application/system loader (defined class path)
– user loader
Problem #2 – ClassNotFoundException
– classes are not visible to the loader
– unintentional ref/dep
– solution: audit cross jar references (Tattletale)
EE class loading model
– child-first allows deployments to override parent classes and jars
— support bundling a diffrent version of a framework than in the ear
– EJB jars share classes with the EAR
– WARs do not share classes, but do see classes in the EAR
– RARs and global EJB-Jars visible to everyone
Problem #3 – ClassCastException on the same name
– duplicate class in isolated loaders
– usually a packaging problem
– common scenario – bundling ejb local interfaces in a WAR
Domain based models (default class loader)
– hot deploy requires classloader per deployment
– normal classloader isolations disallows pass-by-reference
– domains allow class sharing between class loaders
– duplicate classes are resolved using fist-come-first-server
– allows big ball-of-mud
– shared class cache
– default : one domain (defaultDomain) for all, plus one for each WAR
– fix : isolate ears in deployers/ear.deployer
Evolution to module class loaders
– applications don’t always fit hierarchical models
– declare specific dependencies, each jar is a module
— each jar declares dependencies on a name and version
– module system responsible for mapping to class loader (delegation map)
– module has imports and exports
OSGi bundle = module mentioned here, require-bundle, import-package, export-package
AS5 support package and module import/export, jboss-classloading.xml (import=requirements, export-capabilities)
domain style model is also possible
future :
– JDK7 is probably going modular (project jigsaw – JSR-294)
– EE7 will probably follow
– AS7 will be modular
Tattletale can produce module descriptors using a plug-in
Leave a Reply