[JAVA] Object에 대해서 알아보자 2편

1. notify

    @IntrinsicCandidate
    public final native void notify();

Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.
The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

• By executing a synchronized instance method of that object.
• By executing the body of a synchronized statement that synchronizes on the object.
• For objects of type Class, by executing a synchronized static method of that class.

한 객체에 대해서 기다리는 스레드가 있다면, 그 중 하나의 스레드가 활성화 된다.

• synchronized된 인스턴스 메소드가 실행될 때
• synchronized된 코드가 실행될 때
• 클래스 유형의 객체에 대해서는 해당 클래스의 synchronized된 정적  메서드를 실행할 때

여기서 synchronized란 무엇일까?

thread-safe를 하기 위해서 스레드 간 동기화를 시키는 키워드
synchronized 키워드를 설정하면 호출 스레드가 반드시 대상 객체의 고유 락을 갖고 있어야 작동이 된다. 그렇지 않으면 IllegalMOnitorSTateException 에러가 발생한다.

2. notifyAll

    @IntrinsicCandidate
    public final native void notifyAll();

메소드 이름 그대로 기다리고 있는 모든 스레드를 깨우는 역할을 한다.

 

Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.
Throws:

• IllegalMonitorStateException – if the current thread is not the owner of this object's monitor.
  See Also:
  notify(), wait()

3. wait

public final void wait(long timeoutMillis, int nanos) throws InterruptedException {
        if (timeoutMillis < 0) {
            throw new IllegalArgumentException("timeoutMillis value is negative");
        }

        if (nanos < 0 || nanos > 999999) {
            throw new IllegalArgumentException(
                                "nanosecond timeout value out of range");
        }

        if (nanos > 0 && timeoutMillis < Long.MAX_VALUE) {
            timeoutMillis++;
        }

        wait(timeoutMillis);
    }

Causes the current thread to wait until it is awakened, typically by being notified or interrupted, or until a certain amount of real time has elapsed.
The current thread must own this object's monitor lock. See the notify method for a description of the ways in which a thread can become the owner of a monitor lock.
This method causes the current thread (referred to here as T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Note that only the locks on this object are relinquished; any other objects on which the current thread may be synchronized remain locked while the thread waits.
Thread T then becomes disabled for thread scheduling purposes and lies dormant until one of the following occurs:
Some other thread invokes the notify method for this object and thread T happens to be arbitrarily chosen as the thread to be awakened.
Some other thread invokes the notifyAll method for this object.
Some other thread interrupts thread T.
The specified amount of real time has elapsed, more or less. The amount of real time, in nanoseconds, is given by the expression 1000000 * timeoutMillis + nanos. If timeoutMillis and nanos are both zero, then real time is not taken into consideration and the thread waits until awakened by one of the other causes.
Thread T is awakened spuriously. (See below.)
The thread T is then removed from the wait set for this object and re-enabled for thread scheduling. It competes in the usual manner with other threads for the right to synchronize on the object; once it has regained control of the object, all its synchronization claims on the object are restored to the status quo ante - that is, to the situation as of the time that the wait method was invoked. Thread T then returns from the invocation of the wait method. Thus, on return from the wait method, the synchronization state of the object and of thread T is exactly as it was when the wait method was invoked.
A thread can wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. See the example below.
For more information on this topic, see section 14.2, "Condition Queues," in Brian Goetz and others' Java Concurrency in Practice (Addison-Wesley, 2006) or Item 69 in Joshua Bloch's Effective Java, Second Edition (Addison-Wesley, 2008).
If the current thread is interrupted by any thread before or while it is waiting, then an InterruptedException is thrown. 
API Note:
The recommended approach to waiting is to check the condition being awaited in a while loop around the call to wait, as shown in the example below. Among other things, this approach avoids problems that can be caused by spurious wakeups.

synchronized (obj) {       
	while (<condition does not hold> and <timeout not exceeded>) {
    	long timeoutMillis = ... ; // recompute timeout values
        int nanos = ... ;           
        obj.wait(timeoutMillis, nanos);
    }       
        ... // Perform action appropriate to condition or timeout   
}

The current thread must own this object's monitor lock. = 락을 가지고 있어야 한다.

The thread T is then removed from the wait set for this object and re-enabled for thread scheduling.  = wait이 호출되면 현재 락을 가지고 있던 스레드는 해제하고, 스레드는 다시 스레드 스케줄링에 의해 재 사용하게 된다.

If the current thread is interrupted by any thread before or while it is waiting, then an InterruptedException is thrown.  = 현재 락을 가지고 있는 스레드가 에러를 만나게 되면 InterruptedException 를 내게 된다.

 

4. finalize

    @Deprecated(since="9")
    protected void finalize() throws Throwable { }

Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. A subclass overrides the finalize method to dispose of system resources or to perform other cleanup.
The general contract of finalize is that it is invoked if and when the Java virtual machine has determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, except as a result of an action taken by the finalization of some other object or class which is ready to be finalized. The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded.
The finalize method of class Object performs no special action; it simply returns normally. Subclasses of Object may override this definition.
The Java programming language does not guarantee which thread will invoke the finalize method for any given object. It is guaranteed, however, that the thread that invokes finalize will not be holding any user-visible synchronization locks when finalize is invoked. If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.
After the finalize method has been invoked for an object, no further action is taken until the Java virtual machine has again determined that there is no longer any means by which this object can be accessed by any thread that has not yet died, including possible actions by other objects or classes which are ready to be finalized, at which point the object may be discarded.
The finalize method is never invoked more than once by a Java virtual machine for any given object.
Any exception thrown by the finalize method causes the finalization of this object to be halted, but is otherwise ignored.

 

Deprecated
The finalization mechanism is inherently problematic. Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks; there is no way to cancel finalization if it is no longer necessary; and no ordering is specified among calls to finalize methods of different objects. Furthermore, there are no guarantees regarding the timing of finalization. The finalize method might be called on a finalizable object only after an indefinite delay, if at all. Classes whose instances hold non-heap resources should provide a method to enable explicit release of those resources, and they should also implement AutoCloseable if appropriate. The ref.Cleaner and ref.PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable.

 @Override   
 protected void finalize() throws Throwable {
 	try {
    	... // cleanup subclass state       
    } finally {
    	super.finalize();       
    }   
 }

 is to perform cleanup actions before the object is irrevocably discarded. 

(Equal) 예기치 못한 상황에서 수행된다.(here are no guarantees regarding the timing of finalization)

 

It is guaranteed, however, that the thread that invokes finalize will not be holding any user-visible synchronization locks when finalize is invoked. If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.

 

finalize 가 일어날 때 락을 가지고 있지 않을 수 있다. 

(Equal)  자원누수가 일어나고 퍼포먼스에 악영향을 끼치게 된다.

Finalization can lead to performance issues, deadlocks, and hangs. Errors in finalizers can lead to resource leaks