downsides/overhead of stashing & restoring (probably empty) ThreadContextMap ?

TL;DR: Are there any serious performance concerns to be aware of with 
using something like...

doFilter(ServletRequest req, ServletResponse rsp, FilterChain c) {
   final Map<String,String> ctx = ThreadContext.getContext();
   try {
     c.doFilter(req,rsp);
   } finally {
     ThreadContext.clearMap()
     if ( ! ctz.isEmpty() ) { // typically empty
       ThreadContext.putAll(ctx);
     }
   }
}

 	...

I'm dealing with a Servlet Container application where (I think) I'd like 
to (somewhat defensively) stash & later restore the ThreadContext Map data 
as the first & last actions of a ServletFilter that processes evey 
request.

The idea being that I want to garuntee that the only ThreadContext MDC 
values that exist in each (re-used) Thread when it initially starts 
processing a request are the ones set by the ServletContainer itself (if 
any) and that if any "leaked" MDC values still exist at the end of the 
request, I want to ensure they are cleaned up -- not just as a defensive 
measure against "bad code" that might call ThreadContext.put("foo",...) 
w/o also calling ThreadContext.remove("foo"), but also because there are 
some situations where modules/plugins of the application want to 
explicitly set MDC values that exist for the duration of the requests 
lifecycle - even once the module/plugin is "done" with the request (ie: 
userId)

This _seems_ like something that would be very commonly done -- not 
just in Servlet Containers but in any application where Threads get 
re-used to process data/messages.  I assumed if I went looking I'd find 
lots of examples of this pattern in open source code, and/or utility 
classes or helper plugins that bundle up this type of "Snapshot the 
Context Map" logic in an AutoClosable ... but so far nothing.

Which leads me to wonder if this is because there is "enough" overhead (in 
the ThreadContext internals) when doing this that it's not recommended 
except as a last resort?   (I poked around in the code a bit, but between 
not being much of a concrrency expert, nor a log4j expert, nor a garbage 
free expert - I got a little lost in being confident I understood what the 
impacts were in the common/uncommon case)


So ultimatley I'm just hopeing someone can give me some advice on when/if 
code like what I posted above would be a "bad idea" vs a "good idea" ?


-Hoss