DHCP and its lease

The lease is set to one month.  …  What will happen to client PC's  IP if the DHCP server unavailable?
Will the client PC keep the IP remain same when we reboot the PC?

If you are within the regular lease time and restart the PC, it will often get the same IP address. If outside the lease time and if DHCP fails and if you restart, you often get a new IP address.

If a particular computer needs the same IP Address, reserve it with MAC address in DHCP reservations. I do this at client so my consulting machine always has the same IP Address for non-client Email.

By default DHCP clients attempt to renew their lease when half the expiration time has elapsed.  In this scenario, your DHCP server would have to be down a full month before anything bad happened.

After the lease expires, the client must relinquish its lease and the client will be without IP addressing information.  Unless otherwise configured, the client will continue to try to contact a DHCP server every few minutes, but will otherwise be unable to communicate.

If dhcp server is unavailable, client will retain online / ip leased until it reboots
Upon reboot if dhcp server is not available, it keeps finding dhcp and since dhcp is not available, it will remain in apipa mode and don't get ip

This is true that client try to retain same ip until lease expires, however for doing so, dhcp authorization is required, Client request same ip as previous to dhcp and as long as dhcp is online, it can provide authorization to lease and client comes online
If dhcp is offline, client remains with apipa

@paul, because lease renewal will be 1 Month, then on avarage part of the systems will already have their lease 2 weeks, and are in the phase of trying to renew. So i would expect "bad Things" to happen after 2 weeks of down time.
Only the system that received a renewal immediately prior to down time will have a full month.

If the lease Expires when there is no DHCP server the client decides if it gives up the lease or continues to use it. Described previously.
If  a system is started / reconnected in an environment without DHCP server and without a static assignment then an APIPA (Link Local automatic address generation) address will be generated.   With 169.254.x.x/16 as address. see: https://tools.ietf.org/html/rfc3927

Yes, mine was a best-case scenario.  I tried to illustrate the lifespan of a DHCP client, and respond to the OP's three questions.

While not all clients use APIPA, and a client that can use APIPA won't necessarily have it enabled, I take your point regarding it.

Will the client PC keep the IP remain same when we reboot the PC?

I decided to do a little testing on this, as I've been unclear on the Windows DHCP client behavior during a reboot. I set up DHCP on a 2012 R2 server with a single Windows 10 client on the network. After confirming that the client obtained an IP lease, I started a Wireshark capture on the DHCP server and shut down the client. Wireshark showed no DHCP traffic from the client during the shutdown, so the client did not explicitly give up its lease. The DHCP console on the server confirmed this, as it still showed the active lease.

When I booted the client back up, Wireshark showed a DHCP request packet from source address 0.0.0.0 to destination 255.255.255.255 (a network-wide broadcast). Digging into the contents of the packet confirmed that it was from the client. (It couldn't have been from anywhere else, but may as well check.) The server responded with DHCP ACK packet. I noticed that the lease time changed on the client to match the time it was booted back up, and the expiration time changed accordingly. So the client essentially performed a rebinding operation.

This makes sense when you think about it. Even though the DHCP client's lease is still within its validity period when it boots back up, it has no way of knowing what may have happened to the server in the meantime, so it broadcasts out a renewal request (technically a rebind request) just to make sure it can still use the leased address. If the server had leased out that address while the client was down, it would've responded with a NACK, and the lease process would have to start over. A DHCP server won't randomly decide to hand out a leased address to a different client while the lease is still valid, but instead of simply assuming its address is still safe to use (since, for all the client knows, the old DHCP server might be a smoking hole in the ground now), the client plays it safe.

Next, I stopped the DHCP Server service and rebooted the client again. When the client came back up, it broadcast a request like last time, but this time it got no response.  It sent out six more requests at intervals of a few seconds before stopping. It kept the same address, though. Oddly, ipconfig /all showed that the lease time had updated even though the server never responded. That part doesn't make sense to me.

If the client fails to locate a DHCP server during the renewal process, it attempts to ping the default gateway listed in the current lease, with the following results...

I don't think this is valid anymore. That article was written for Windows 2000, and it's possible that newer OSes use some other method to determine whether they're still connected to the same network. In any case, during my tests, there was never any ping traffic coming from the client to its gateway. (The DHCP server was also the default gateway for the client's network, so it would've shown up in the capture.)

DHCP has a few phases:  https://www.ietf.org/rfc/rfc2131.txt
Discovery    - Broadcast from ME (0.0.0.0, MAC from source interface) to EVERYONE (255.255.255.255, mac FF:...:FF)  on this segment
Offer            - the answer would be from any DHCP server (a reply, from an IP address, MAC address, to: mac address of requesting system).
Request       - Request to specific DHCP server (one may ask for a specific address f.e. the old address) , answer is a proposal. ....
Confirm        - Server indicates OK. (Now the DNS will be updated etc.)

Renewal only do the Request/Confirmation ...
Strange it updated the server response, while not getting one.

Right; those phases (usually abbreviated DORA) describe the initial lease process. You're right that renewals use directed (unicast) request packets, but if the client ever gets to the rebinding phase (if it hasn't received a response from the original DHCP server by the time 7/8ths of the lease time expires), it starts broadcasting those request packets so that any DHCP server on the network can respond. It appears to do the same thing after a reboot, from what I've just seen.

I have no windows system so i can't verify this.
My Unix systems release the address and stop working upon end of lease.

I don't think there's anything in the DHCP RFCs that governs that behavior, so it doesn't surprise me that different OSes would behave differently in that respect. Heck, I wouldn't be surprised if different Windows versions did it differently too.