sp_who2 (or sysprocesses or sys.dm_exec_requests) might show your thread being blocked by SPID -4

You might find that when sp_who2 (or sys.sysprocesses or sys.dm_exec_requests) is executed on a SQL Server, the output has several threads facing blocking
If you track the blocking chain, you will reach to a thread that is being blocked by a SPID with number -4.
About this -4 SPID, BOL says (https://msdn.microsoft.com/en-us/library/ms177648.aspx):

-4 = Session ID of the blocking latch owner could not be determined due to internal latch state transitions.

What to do: 

* If you see this scenario, focus on the waitresource this spid -4 was working. In our case is was 2:1:103
* This was a page from tempdb (2:1:103  = 2 - database ID i.e. tempdb)
* If you see the -4 SPIDs being waiting for the same waitresource, you can be sure there is a page hotspot condition going on.
* In my case, found that a new code that uses table variables was implemented. Every client was firing this query almost every second.
* Since it was using a default setup, the table variable was getting allocated on the same page causing that db page (in our case 2:1:103) to become a hotspot causing tempdb contention

To resolve this issue, carefully follow east step from https://support.microsoft.com/kb/328551 and check for

Repeated create and drop of temporary tables (local or global).
Table variables that use tempdb for storage purposes.
Work tables associated with CURSORS.
Work tables associated with an ORDER BY clause.
Work tables associated with an GROUP BY clause.
Work files associated with HASH PLANS.

* You can implement TF 118 (as per the above KB article) to have the issue subsided (In my case, the blocking impact went down considerably).
* Final resolution is change the code to use temp tables instead of table variables