> string 自体がリファレンスカウントの機能を持たず、
> 言語としてガベコレの機構を持つ場合にはマルチスレッド
> 性能の低下は招かないの？たとえばC#とか。

ちょっとチラシの裏借りますね

C#(というか.NET)やJavaの最近の実装は、若いオブジェクトのための
ヒープのようなものをスレッドごとに持つ。
ガベコレが動作しない間はこのヒープ状のものはロックされない。
だからstringを作って足してコピーして・・・なんかを繰り返しても、
他スレッドの動作を(同期機構を使わないという点で)妨げることはない。
ただし、live objectが超大量になると、ガベコレ期間が悲惨なことになる。
大規模アプリ、Eclipseなんかが苦労してる。

一方、C/C++は通常はヒープがスレッドごとじゃないから、new/delete/
malloc/freeするたびにヒープのロックが発生する。複数スレッドが
new/deleteをガンガンやるとひどいことになりかねない。
std::mapをコピーすると結構起こってそうなんだがどうだろう。
スレッドごとに独立していることが保証されているなら、カスタム
アロケータの利用を考えてもよいかもしれない。でも、スレッド間で
安全に受け渡すのが難しくなるという諸刃の剣。素人にはおすすめしない。

オブジェクトのサイズや個数、ライフサイクルなんかに依存しまくる話だから
一般的にこうすべし、というのは言いにくいんだよね。
逆にいうとC#やJavaが取っている手法法は「使いすてオブジェクト多杉」
という一般的な傾向から導かれたものだから、参考にしてもよいと思う。

２年以上前の知識ゆえ間違ってたら指摘夜露死苦

以上、チラシの裏でした。