Re: Thread Safety: Was (Native sFTP?)

[James Perkins <jrperkinsjr@xxxxxxxxx>]

Very valid argument. I guess at that point I would look at it. I don't
generally create a lot of concatenated strings, but if I'm concatenating
more than a 3 or 4 strings, I generally use a StringBuilder. Of course
that's just a personal preference. So, if I needed to concatenate a huge
string based on different threads, StringBuffer would be the choice. With my
test StringBuilder was only about 50ms faster, not a whole lot in the scheme
of things.

I guess I rely quite a bit on the garbage collector. It's been improved so
much that you really don't even have to think about it, and I can't remember
the last time I made a huge memory foot print without trying too.
--
James R. Perkins


On Mon, Apr 27, 2009 at 21:26, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

> > From: James Perkins
> > It's not risky at all. You don't have to synchronize variables that
> > are inside a method.
>
> I concede the point to the extent that the SringBuilder object in question
> is "new" and "local" to a method, as opposed to a StringBuilder object which
> is scoped to the class - an instance variable.  I've read several sources
> that indicate local variables use "stack" storage as opposed to "heap"
> storage, and that every thread has its own stack.
>
> But that raises the question of its applicability.  Say a new instance of a
> StringBuilder object is created with each method call from each thread in a
> Web application.  Is the method used a lot?  Does it allocate a lot of
> memory - appending strings?  StringBuilder may perform better than
> StringBuffer.  But how long before you've left a big trail of garbage to be
> collected by the garbage collector?  Would it solve one problem and create
> another?
>
> Nathan.
>
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.