anoop ashtekar wrote:
Hello Friend,
Congrats about passing scjp 6 . kindly brief me up the topics on which you majorly
had questions in the exam
Once again congrats And all the best for your further endeavours!!
Thanks
Anup
Sebanti Sanyal wrote:Inside method go(),two objects are created. f3 refers tothe object originally referred by f2. That particular object has a member variable f,which again refers to the object initially referenced by f1. Therefore, none of the two are eligible for GC at line 18. If we also had f3=null;, the two objects would still had referenced each other but none of them could be accessed externally and hence eligible for GC.
In main(),one object is created on which go() was invoked.That object was created on the go,and there is no reference associated with it.Hence, it is definitely eligible for GC at line 8.The two objects created inside go() were accessible only with a local variable f3,which does not live anymore after go() returns. These two can also be garbage collected at line 8.
Larsen Raja wrote:Missed the SOP in getH functions.
1. In any statement if there is an internal call to a method that method gets executed frist.
For example: If theres a call to a method A() in main(), A() needs to be completed first before main() reaches termination.
Likely, A(B()); In this case, B() needs to be executed first before A() returns.
Henry Wong wrote:
Please QuoteYourSources
Ankit Gareta wrote:Here in SOP it called the override method... so the answer should be something like that....
Beta 44
4 44
Beta 44
44 44
as Laren said... the variabels will be used based on the reference type. so in first SOP the b.h = 4 ...
Tina Smith wrote:You should synchronize on the class in your run() method, not in main where the threads are being constructed.
Because threadcounter is static and shared by all instances of TestClass (and exists even without an instance of TestClass), you can't lock on an individual instance of TestClass. So what you need is to be able to lock all objects out from accessing threadcounter while you are using it. You could always declare a static Object in TestClass and then lock on that object to lock the primitive, but Java provides a more elegant, built-in way of doing this: TestClass.class. There is only one ".class" for all instances of TestClass, so locking the "class" field will lock anything shared.
I probably should remember whether locking the class locks the instance methods/fields as well...I seem to think it doesn't but again I could be wrong.
Synchronized will lock on whatever you give it, if you try to lock on any instance of TestClass you won't have much luck; because threadcounter is static your lock object MUST also be static. You're also in the same boat if you provide getters and setters; they have to return a primitive which you cannot lock.