Recently I wondered about the performance cost of preemptively putting monitor locks on small library methods that might conceivably be called from multiple threads. That’s a great subject for a micro-benchmark, so I wrote a few tests in C# and Java and posted the results in Uncontested Lock Performance.
As it turns out, standard locking mechanisms on both platforms are not quite as cheap as one might hope for in the uncontested case. They are about as expensive as getting the next integer from the standard random number generator, i.e. trivial compared to significant chunks of work but rather too expensive to wrap around any old static library method by default.
2015-09-21: Added a second set of test results for my current hardware & software. The original results reproduced nicely, so I could keep my analysis mostly unchanged. Microsoft’s .NET reader/writer locks did become relatively faster in .NET 4.6, though not enough to change my recommendations.