Problems with StringBuffers synchronized methods

[chris brat]

Hi,

A colleague of mine recently told me that he once wrote a web
application that made very heavy use of StringBuffer class (JVM version
1.3) in order to generate code (using Javacc) and experienced the
problem of running out of file handles.

It was explained to me that the problem was due to the synchronized
methods of the StringBuffer class and all the thread locking associated
with using it.

This sounds very interesting and could explain a problem I had at a
previous company.

Thanks
Chris

 

[Philipp Leitner]

Hi,

A colleague of mine recently told me that he once wrote a web
application that made very heavy use of StringBuffer class (JVM version
1.3) in order to generate code (using Javacc) and experienced the
problem of running out of file handles.

It was explained to me that the problem was due to the synchronized
methods of the StringBuffer class and all the thread locking associated
with using it.

This sounds very interesting and could explain a problem I had at a
previous company.

Thanks
Chris

Not that I could much informative here, but it also is an interesting
point concerning a problem that I currently have at work ... does
anybody know anything more on this?

/philipp

 

[Mike Schilling]

Hi,

A colleague of mine recently told me that he once wrote a web
application that made very heavy use of StringBuffer class (JVM version
1.3) in order to generate code (using Javacc) and experienced the
problem of running out of file handles.

It was explained to me that the problem was due to the synchronized
methods of the StringBuffer class and all the thread locking associated
with using it.

Unless the StringBuffer instances are used in multiple threads, the fact
that their methods are synchronized should be, at worst, a minor performance
issue. If they are used in multiple threads (unlikely, for code
generation), they'd better be synchronized.

Nonetheless, in Java 1.5 and later, for single-threaded use StringBuilder is
preferred.

 

[Chris Uppal]

It was explained to me that the problem was due to the synchronized
methods of the StringBuffer class and all the thread locking associated
with using it.

I'm having difficulty imagining any possible way that locks and files could be
connected.

Here are the closest I can get.

a) StringBuffer operations are synchronised, hence slower, thus the String
processing took longer -- say it doubled the overall time needed to process one
requiest. That means that the average number of requests "in flight" at any
one time will double (or more than double). That in turn means that the number
of files open at any one time doubles (or more than doubles). Which causes the
overall app to exceed some system limit.

b) For some unimaginable reason the app had several/many threads writing to
many StringBuffers as a many-to-many relationship (/very/ strange application
design!). So each of the many SBs is /actually/ contended. This means that
the JVM has to "inflate" the locks used for the objects from "thin locks" into
full OS-level semaphores. If the OS was such that the "handles" allocated for
the semaphores came out of the same pool as were used for open files (but
why??), then a huge number of semaphores might exhaust the available file
handles.

c) Same as (b) but assuming that the 1.3 JVM didn't have the thin lock
optimisation, in which case the huge number of symultaneous SBs would might
force the JVM to allocate lots of OS-level semaphores even though the SBs were
not actually contended. I can't remember when the thin lock optimisation was
added, I believe that the previous implementation used hashing scheme to reduce
the number of semaphores needed (several independent objects shared one
OS-level semaphore).

I suppose (c) is the least implausible, especially if you further assume that
"running out of file handle" is just a confused expression for "running out of
OS-level semaphores".

-- chris