在 java/c# 这样基于引用语义处理字符串的语言中，作为不可变对象存在的字符串，如果内容相同，则可以通过某种机制实现重用。因为对这类语言来说，指向内存中两块内存位置不同内容相同的字符串，与同时指向一个字符串并没有任何区别。特别是对大量使用字符串的 xml 文件解析类似场合，这样的优化能够很大程度上降低程序的内存占用，如 sax 解析引擎标准中就专门定义了一个 http://xml.org/sax/features/string-interning 特性用于字符串重用。

　　在语言层面，java/c# 中都直接提供了 string.intern 的支持。而对 java 来说，实现上的非常类似。由 string.intern 方法，将当前字符串以内容为键，对象引用为值，放入一个全局性的哈希表中。

　　代码:

// // java/lang/string.java // public final class string { 　//... 　public native string intern(); // 使用 jni 函数实现以保障效率 } // // hotspot/src/share/vm/prims/jvm.cpp // jvm_entry(jstring, jvm_internstring(jnienv *env, jstring str)) jvmwrapper("jvm_internstring"); if (str == null) return null; 　oop string = jnihandles::resolve_non_null(str); // 将引用解析为内部句柄 　oop result = stringtable::intern(string, check_0); // 进行实际的字符串 intern 操作 　return (jstring) jnihandles::make_local(env, result); // 获取内部句柄的引用 　jvm_end 　// 　// hotspot/src/share/vm/memory/symboltable.cpp 　// 　oop stringtable::intern(oop string, traps) 　{ 　　if (string == null) return null; 　　resourcemark rm(thread); // 保护线程资源区域 　　int length; 　　handle h_string (thread, string); 　　jchar* chars = java_lang_string::as_unicode_string(string, length); // 获取实际字符串内容 　　oop result = intern(h_string, chars, length, check_0); // 完成字符串 intern 操作 　　return result; 　} 　oop stringtable::intern(handle string_or_null, jchar* name, int len, traps) 　{ 　　int hashvalue = hash_string(name, len); // 首先根据字符串内容计算哈希值 　　stringtablebucket* bucket = bucketfor(hashvalue); // 根据哈希值获取目标容器 　　oop string = bucket->lookup(name, len); // 然后检测字符串是否已经存在 　　// found 　　if (string != null) return string; 　　// otherwise, add to symbol to table 　　return basic_add(string_or_null, name, len, hashvalue, check_0); // 将字符串放入哈希表 　}

　　对全局字符串表中的字符串，是没有办法显式手动清除的。只能在不使用此字符串后，由垃圾回收线程在进行不可达对象标记时进行分析，并最终调用 stringtable::unlink 方法去遍历清除。

　　代码：

// // hotspot/src/share/vm/memory/genmarksweep.cpp // void genmarksweep::mark_sweep_phase1(...) { 　//... 　stringtable::unlink(); } // // hotspot/src/share/vm/memory/symboltable.cpp // void stringtable::unlink() { 　// readers of the string table are unlocked, so we should only be 　// removing entries at a safepoint. 　assert(safepointsynchronize::is_at_safepoint(), "must be at safepoint") 　for (stringtablebucket* bucket = firstbucket(); bucket <= lastbucket(); bucket++) { 　　for (stringtableentry** p = bucket->entry_addr(); *p != null;) { 　　　stringtableentry* entry = *p; 　　　assert(entry->literal_string() != null, "just checking"); 　　　if (entry->literal_string()->is_gc_marked()) { // 字符串对象是否可达 　　　　// is this one of calls those necessary only for verification? (dld) 　　　　entry->oops_do(&marksweep::follow_root_closure); 　　　　p = entry->next_addr(); 　　　} else { // 如不可达则将其内存块回收到内存池中 　　　　*p = entry->next(); 　　　　entry->set_next(free_list); 　　　　free_list = entry; 　　　} 　　} 　} }

　　通过上面的代码，我们可以直观了解到，对 jvm (sun jdk 1.4.2) 来说，string.intern 提供的是全局性的基于哈希表的共享支持。这样的实现虽然简单，并能够在最大限度上进行字符串共享;但同时也存在共享粒度太大，优化效果无法度量，大量字符串可能导致全局字符串表性能降低等问题。

　　为此 eclipse 舍弃了 jvm 一级的字符串共享优化机制，而通过提供细粒度、完全可控、可测量的字符串分区共享优化机制，一定程度上缓解此问题。eclipse 核心的 istringpoolparticipant 接口由使用者显式实现，在其 sharestrings 方法中提交需要共享的字符串。

　　代码:

// // org.eclipse.core.runtime.istringpoolparticipant // public interface istringpoolparticipant { 　/** 　* instructs this participant to share its strings in the provided 　* pool. 　*/ 　public void sharestrings(stringpool pool); }

　　例如 markerinfo 类型实现了 istringpoolparticipant 接口，在其 sharestrings 方法中，提交自己需要共享的字符串 type，并通知其下级节点进行相应的提交。

　　代码:

// // org.eclipse.core.internal.resources.markerinfo // public class markerinfo implements ..., istringpoolparticipant { 　public void sharestrings(stringpool set) { 　　type = set.add(type); 　　map map = attributes; 　　if (map instanceof istringpoolparticipant) 　　((istringpoolparticipant) map).sharestrings(set); 　} }

　　这样一来，只要一个对象树各级节点选择性实现 istringpoolparticipant 接口，就可以一次性将所有需要共享的字符串，通过递归提交到一个字符串缓冲池中进行复用优化。如 workspace 就是这样一个字符串共享根入口，其 open 方法在完成工作区打开操作后，将需要进行字符串共享优化的缓存管理对象，加入到全局字符串缓冲区分区优化列表中。

　　代码:

// // org.eclipse.core.internal.resources // public class workspace ... { 　protected savemanager savemanager; 　public istatus open(iprogressmonitor monitor) throws coreexception 　{ 　　// 打开工作空间 　　// 最终注册一个新的字符串缓冲池分区 　　internalplatform.getdefault().addstringpoolparticipant(savemanager, getroot()); 　　return status.ok_status; 　} }

　　对需要优化的类型 savemanager 来说，只需要实现 istringpoolparticipant 接口，并在被调用的时候提交自己与子元素的需优化字符串即可。其子元素甚至都不需要实现 istringpoolparticipant 接口，只需将提交行为一级一级传递下去即可，如:

　　代码:

// // org.eclipse.core.internal.resources.savemanager // public class savemanager implements ..., istringpoolparticipant { 　protected elementtree lastsnap; 　public void sharestrings(stringpool pool) 　{ 　　lastsnap.sharestrings(pool); 　} } // // org.eclipse.core.internal.watson.elementtree // public class elementtree { 　protected deltadatatree tree; 　public void sharestrings(stringpool set) { 　　tree.storestrings(set); 　} } // // org.eclipse.core.internal.dtree.deltadatatree // public class deltadatatree extends abstractdatatree { 　private abstractdatatreenode rootnode; 　private deltadatatree parent; 　public void storestrings(stringpool set) { 　　//copy field to protect against concurrent changes 　　abstractdatatreenode root = rootnode; 　　deltadatatree dad = parent; 　　if (root != null) 　　　root.storestrings(set); 　　if (dad != null) 　　　dad.storestrings(set); 　} } // // org.eclipse.core.internal.dtree.abstractdatatreenode // public abstract class abstractdatatreenode { 　protected abstractdatatreenode children[]; 　protected string name; 　public void storestrings(stringpool set) { 　　name = set.add(name); 　　//copy children pointer in case of concurrent modification 　　abstractdatatreenode[] nodes = children; 　　if (nodes != null) 　　　for (int i = nodes.length; --i >= 0;) 　　　　nodes[i].storestrings(set); 　} }

　　所有的需优化字符串，都会通过 stringpool.add 方法提交到统一的字符串缓冲池中。而这个缓冲池的左右，与 jvm 级的字符串表略有不同，它只是在进行字符串缓冲分区优化时，起到一个阶段性的整理作用，本身并不作为字符串引用的入口存在。因此在实现上它只是简单的对 hashmap 进行包装，并粗略计算优化能带来的额外空间，以提供优化效果的度量标准。

　　代码:

// // org.eclipse.core.runtime.stringpool // public final class stringpool { 　private int savings; 　private final hashmap map = new hashmap(); 　public stringpool() { 　　super(); 　} 　public string add(string string) { 　　if (string == null) 　　　return string; 　　object result = map.get(string); 　　if (result != null) { 　　　if (result != string) 　　　　savings += 44 + 2 * string.length(); 　　　return (string) result; 　　} 　　map.put(string, string); 　　return string; 　} 　// 获取优化能节省多少空间的大致估算值 　public int getsavedstringcount() { 　　return savings; 　} }

　　不过这里的估算值在某些情况下可能并不准确，例如缓冲池中包括字符串 s1，此时提交一个与之内容相同但物理位置不同的字符串 s2，则如果 s2 被提交多次，会导致错误的高估优化效果。当然如果需要得到精确值，也可以对其进行重构，通过一个 set 跟踪每个字符串优化的过程，获得精确优化度量，但需要损失一定效率。

　　在了解了需优化字符串的提交流程，以及字符串提交后的优化流程后，我们接着看看 eclipse 核心是如何将这两者整合到一起的。

　　前面提到 workspace.open 方法会调用 internalplatform.addstringpoolparticipant 方法，将一个字符串缓冲池分区的根节点，添加到全局性的优化任务队列中。

　　代码:

// // org.eclipse.core.internal.runtime.internalplatform // public final class internalplatform { 　private stringpooljob stringpooljob; 　public void addstringpoolparticipant(istringpoolparticipant participant, ischedulingrule rule) { 　if (stringpooljob == null) 　　stringpooljob = new stringpooljob(); // singleton 模式 　　stringpooljob.addstringpoolparticipant(participant, rule); 　} } // // org.eclipse.core.internal.runtime.stringpooljob // public class stringpooljob extends job { 　private static final long initial_delay = 10000;//five seconds 　private map participants = collections.synchronizedmap(new hashmap(10)); 　public void addstringpoolparticipant(istringpoolparticipant participant, ischedulingrule rule) { 　participants.put(participant, rule); 　if (sleep()) 　　wakeup(initial_delay); 　} 　public void removestringpoolparticipant(istringpoolparticipant participant) { 　　participants.remove(participant); 　} }

　　此任务将在合适的时候，为每个注册的分区进行共享优化。

　　stringpooljob 类型是分区任务的代码所在，其底层实现是通过 eclipse 的任务调度机制。关于 eclipse 的任务调度，有兴趣的朋友可以参考 michael valenta (ibm) 的 on the job: the eclipse jobs api 一文。

　　这里需要了解的是 job 在 eclipse 里，被作为一个异步后台任务进行调度，在时间或资源就绪的情况下，通过调用其 job.run 方法执行。可以说 job 非常类似一个线程，只不过是基于条件进行调度，可通过后台线程池进行优化罢了。而这里任务被调度的条件，一方面是任务自身的调度时间因素，另一方面是通过 ischedulingrule 接口提供的任务资源依赖关系。如果一个任务与当前正在运行的任务传统，则将被挂起直到冲突被缓解。而 ischedulingrule 接口本身可以通过 composite 模式进行组合，描述复杂的任务依赖关系。

　　在具体完成任务的 stringpooljob.run 方法中，将对所有字符串缓冲分区的调度条件进行合并，以便在条件允许的情况下，调用 stringpooljob.sharestrings 方法完成实际工作。

　　代码:

// // org.eclipse.core.internal.runtime.stringpooljob // public class stringpooljob extends job { 　private static final long reschedule_delay = 300000;//five minutes 　protected istatus run(iprogressmonitor monitor) 　{ 　　//copy current participants to handle concurrent additions and removals to map 　　map.entry[] entries = (map.entry[]) participants.entryset().toarray(new map.entry[0]); 　　ischedulingrule[] rules = new ischedulingrule[entries.length]; 　　istringpoolparticipant[] torun = new istringpoolparticipant[entries.length]; 　　for (int i = 0; i < torun.length; i++) { 　　　torun[i] = (istringpoolparticipant) entries[i].getkey(); 　　　rules[i] = (ischedulingrule) entries[i].getvalue(); 　　} 　　// 将所有字符串缓冲分区的调度条件进行合并 　　final ischedulingrule rule = multirule.combine(rules); 　　// 在调度条件允许的情况下调用 sharestrings 方法执行优化 　　try { 　　　platform.getjobmanager().beginrule(rule, monitor); // 阻塞直至调度条件允许 　　　sharestrings(torun, monitor); 　　} finally { 　　　platform.getjobmanager().endrule(rule); 　　} 　　// 重新调度任务自己，以便进行下一次优化 　　long scheduledelay = math.max(reschedule_delay, lastduration*100); 　　schedule(scheduledelay); 　　return status.ok_status; 　} }

　　stringpooljob.sharestrings 方法只是简单的遍历所有分区，调用其根节点的 istringpoolparticipant.sharestrings 方法，进行前面所述的优化工作，并最终返回分区的优化效果。而缓冲池本身，只是作为一个优化工具，完成后直接被放弃。

　　代码:

private int sharestrings(istringpoolparticipant[] torun, iprogressmonitor monitor) { 　final stringpool pool = new stringpool(); 　for (int i = 0; i < torun.length; i++) { 　　if (monitor.iscanceled()) // 操作是否被取消 　　　break; 　　final istringpoolparticipant current = torun[i]; 　　platform.run(new isaferunnable() { // 安全执行 　　　public void handleexception(throwable exception) { 　　　　//exceptions are already logged, so nothing to do 　　　} 　　　public void run() { 　　　　current.sharestrings(pool); // 进行字符串重用优化 　　　} 　　}); 　} 　return pool.getsavedstringcount(); // 返回优化效果 } }

　　通过上面的分析我们可以看到，eclipse 实现的基于字符串缓冲分区的优化机制，相对于 jvm 的 string.intern() 来说:

　　1.控制的粒度更细，可以指定要对哪些对象进行优化;

　　2.优化效果可度量，可以大概估算出优化能节省的空间;

　　3.不存在性能瓶颈，不存在集中的字符串缓冲池，因此不会因为大量字符串导致性能波动;

　　4.不会长期占内存，缓冲池只在优化执行时存在，完成后中间结果被抛弃;

　　5.优化策略可选择，通过定义调度条件，可选择性执行不同的优化策略