Eclipse的字符串分区共享优化机制
当前位置：以往代写 > JAVA 教程 >Eclipse的字符串分区共享优化机制

Eclipse的字符串分区共享优化机制

2019-06-14

Eclipse的字符串分区共享优化机制

Eclipse的字符串分区共享优化机制

副标题#e#

在 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); // 将字符串放入哈希表
　 }


#p#副标题#e#

对全局字符串表中的字符串，是没有步伐显式手动排除的。只能在不利用此字符串后，由垃圾接纳线程在举办不行达工具标志时举办阐明，并最终挪用 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 要领中提交需要共享的字符串。

代码:

#p#分页标题#e#

//
// 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);
　 }
}

#p#副标题#e#

这样一来，只要一个工具树各级节点选择性实现 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);
　 }
}

#p#副标题#e#

所有的需优化字符串，城市通过 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;
　 }
}

#p#分页标题#e#

不外这里的估算值在某些环境下大概并禁绝确，譬喻缓冲池中包罗字符串 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);
　 }
}

#p#副标题#e#

此任务将在符合的时候，为每个注册的分区举办共享优化。

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;
　 }
}

#p#分页标题#e#

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.优化计策可选择，通过界说调治条件，可选择性执行差异的优化计策

    关键字：

在线提交作业