Thanks for your reply. As you guessed, these non-volatile properties is initialized in a single thread by invocation of method "HMaster.finishActiveMasterInitialization(MonitoredTask status)" and won't be changed anymore. And now I get it, the way in which HMaster initialize itself. It use a single thread to initialize its properties that won't change, and then use this single thread to start other threads that will access the unchanged properties. According to "happens-before" rule, threads started by the single thread would see any memory change made by the single thread before. Am I right?
Stack <[email protected]> 于2019年3月15日周五 下午12:39写道： > On Thu, Mar 14, 2019 at 12:34 AM yuhang li <[email protected]> wrote: > > > Hi all, I'm developing some new features based on HBase-1.2.9 > > > Its best to develop against master first and then we backport to other > branches. > > You've seen announcements that hbase-1.2 is sunsetting.... that it'll be > EOL'd in the not too distant future? > > > > > and found a > > weird thing that， in class HMaster some properties are volatile, while > > others are not volatile and I haven't found any synchronization for > them. > > As far as I know, volatile is use to to guarantee visibility among > multiple > > threads. There is no doubt HMaster is accessed by many threads. So, why > > there are only a small part of variables are volatile? > > > > > Maybe paste an example of what you think a problematic use of volatile? > That might be the best way to proceed. If non-volatile, then my guess is it > is a property that is written on single-threaded startup and not changed > ahead of the rest-of-all threads starting. > > Thanks, > S >
