切片后释放字符串以进行垃圾回收的正确方法
根据此Go Data Structures文章的介绍，在“ 字符串”
部分下，它声明获取字符串的一部分会将原始字符串保留在内存中。
“（顺便说一句，在Java和其他语言中，有一个众所周知的陷阱，当您对字符串进行切片以保存一小段时，对原始字符串的引用会将整个原始字符串保留在内存中，即使仍然很少Go也有这个陷阱。我们尝试并拒绝的替代方法是使字符串切片变得如此昂贵（分配和复制），以至于大多数程序都避免了。）”
因此，如果我们有一个很长的字符串：
s := "Some very long string..."
我们采取一小部分：
newS := s[5:9]
在s我们也发布之前，不会发布原始文件newS。考虑到这一点，如果我们需要保持newS长期状态，但s为了垃圾回收而释放，该采取什么适当的方法呢？
我想也许是这样的：
newS := string([]byte(s[5:9]))
但是我不确定这是否会切实可行，或者是否有更好的方法。
问题答案：
是的，转换为字节的一部分将创建该字符串的副本，因此不再引用原始的字符串，并且可以在行下的某处进行GC处理。
作为对此的“证明”（很好，它证明了字节片与原始字符串不共享相同的基础数据）：
http://play.golang.org/p/pwGrlETibj
编辑：并证明字节片仅具有必要的长度和容量（换句话说，其容量不等于原始字符串的容量）：
http://play.golang.org/p/3pwZtCgtWv
Edit2：您可以清楚地看到内存配置文件发生了什么。在reuseString（）中，使用的内存非常稳定。在copyString（）中，它增长很快，显示了[]
byte转换完成的字符串的副本。
http://play.golang.org/p/kDRjePCkXq
-
问题内容： 我很好奇嵌套函数的node.js模式如何与v8的垃圾收集器一起工作。这是一个简单的例子 如果restofprogram是长时间运行的，那是否不意味着str将永远不会被垃圾回收？我的理解是，使用结点，您最终会获得很多嵌套函数。如果在外部声明了restofprogram，是否会收集垃圾，因此str不能在范围内？这是推荐做法吗？ 编辑 我不想使问题复杂化。那只是粗心，所以我修改了它。 问题答
-
问题内容： 我正在阅读有关垃圾收集的信息，当我搜索字符串文字垃圾收集时，搜索结果令人困惑。 我需要澄清以下几点： 如果在编译时将字符串定义为文字字符串，那么是否会对其进行垃圾回收？ 如果使用实习方法，那么它会被垃圾回收吗？在第1点中，它也将与文字区别对待。 有人提到只有在卸载类时才会对文字进行垃圾回收吗？是否有道理，因为我认为永远不会卸课。 问题答案： 如果在编译时将字符串定义为文字字符串，那么是
-
垃圾回收 我们对生产中花了很多时间来调整垃圾回收。垃圾回收的关注点与Java大致相似，尽管一些惯用的Scala代码比起惯用的Java代码会容易产生更多(短暂的)垃圾——函数式风格的副产品。Hotspot的分代垃圾收集通常使这不成问题，因为短暂的(short-lived)垃圾在大多情形下会被有效的释放掉。 在谈GC调优话题前，先看看这个Attila的报告，它阐述了我们在GC方面的一些经验。 Scal
-
对于开发者来说，JavaScript 的内存管理是自动的、无形的。我们创建的原始值、对象、函数……这一切都会占用内存。 当我们不再需要某个东西时会发生什么？JavaScript 引擎如何发现它并清理它？ 可达性（Reachability） JavaScript 中主要的内存管理概念是 可达性。 简而言之，“可达”值是那些以某种方式可访问或可用的值。它们一定是存储在内存中的。 这里列出固有的可达值的
-
垃圾收集，引用计数，显式分配 和所有的现代语言一样，OCaml提供垃圾收集器，所以你不用像C/C++一样显式地分配和释放内存。 JWZ在他的文章 "Java sucks" rant（Java蛋疼（怒）！）: 第一个好家伙是Java没有 free()。其他的都没有所谓了。这几乎掩盖了所有的缺点，不管有多糟糕， 这个有点让后续文档基本都没有意义了，但是...（译注：但是啥大家自己看吧） OCaml的垃
-
问题内容： 如果我使用String.intern（）来提高性能，因为我可以使用“ ==”来比较内部字符串，是否会遇到垃圾回收问题？内联字符串的垃圾回收机制与普通字符串有何不同？ 问题答案： 实际上，这不是垃圾收集优化，而是字符串池优化。调用时，您用其基本引用（首次遇到此字符串的引用，如果尚不知道此引用，则为参考）替换对初始String的引用。 但是，一旦您的字符串不再在应用程序中使用，它将成为垃圾