[SalesForce] Future Method Static

Given that the reason to use a future method is to separate the DML of the User from the DML of the Contact object, only one of these DML needs to move to a future method. The change driving the process is the change to the User, so it seems natural to keep that logic synchronous and move the change to the Contact out into the future: Contact will always follow User.

So if I was writing this, I would use this trigger:

trigger UserInsertUpdate on User (before insert, after insert, after insert,after update) {

    if (Trigger.isBefore) {
        // Update market name to match market unit on the User.
        // As this is a before trigger no update is needed.
        // A trigger on Market__c would also be needed if the
        // Name/Unit_Number__c combinations ever change.
        Map<String, String> m = new Map<String, String>();
        for (User u : Trigger.new) {
            if (u.True_Market_Unit__c != null) {
                m.put(u.True_Market_Unit__c, null);
            }        
        }
        for (Market__c market : [
                SELECT Name, Unit_Number__c
                FROM Market__c
                WHERE Unit_Number__c IN :m.keySet()
                ]){
            m.put(market.Unit_Number__c, market.Name);
        }
        }
        for (User u : Trigger.new) {
            u.True_Market_Name__c = m.get(u.True_Market_Unit__c);  
        }
    } else {
        // Has to be in a different transaction to avoid a mixed DML exception.
        SyncContactsToUsers.sync(Trigger.newMap.keySet());
    }
}

and this class:

public class SyncContactsToUsers {

    public class SyncContactsToUsersException extends Exception {
    }

    @future
    public static void sync(Set<Id> userIds) {

        // Find existing related Contacts (if any)
        Map<Id, Contact> m = new Map<Id, Contact>();
        for (Contact c : [
                select Id, Related_User__c
                from Contact
                where Related_User__c in :userIds
                ]) {
            m.put(c.Related_User__c, c);
        }

        // Update existing or insert new Contacts with values consistent with User
        Id accountId = queryAccountId();
        Contact[] upserts = new Contact[] {};
        for (User u : [
                select FirstName,LastName,True_Market_Name__c,Email,Phone,Id,isActive
                from User
                where Id in :userIds
                ]) {
            Contact c = m.get(u.Id);
            if (c == null) {
                c = new Contact(Related_User__c = u.Id);
            }
            c.FirstName = u.FirstName;
            c.LastName = u.LastName;
            c.User_True_Market_Name__c = u.True_Market_Name__c;
            c.Email = u.Email;
            c.Phone = u.Phone;
            c.OwnerID = u.Id;
            c.AccountId = accountId;
            c.Contact_Status__c = u.isActive ? 'Active' : 'Inactive';
            upserts.add(c);
        }
        upsert upserts;
    }

    private static queryAccountId() {

        // Find the Account or insert it if its missing
        final String accountName = 'Company Users';
        Account[] accounts = [
                SELECT Id
                FROM Account
                WHERE Name = :accountName
                ];
        Id accountId;
        if (accounts.size() == 1)  {
            return accounts[0].Id;
        } else if (accounts.size() == 0) {
            Account a = new Account(Name = accountName);
            insert a;
            return a.Id;
        } else {
            // Don't want to attach Contacts to the wrong Account.
            // If more than 1 don't know which one to use.
            throw new SyncContactsToUsersException(''
                    + 'More than one Account with name '
                    + accountName
                    + '; contact your System Administrator to address'
                    );
        }
    }
}

Both probably contain typos.

If the above code still results in "ENTITY_IS_LOCKED" DmlExceptions, then moving to using the Queueable mechanism instead of the future mechanism is probably going to be necessary so you can catch the exception and retry. (You can't kick-off a new future method from a future method.) Skipping work if you are already in a future context won't work as legitimate updates of unrelated objects could get dropped.

Future methods can be debugged in two ways. First, you can open the developer console and perform the action that causes the future method to be called. Second, you can enable debug logs in Setup / Monitoring / Debug Logs.

As for telling if they have executed, check out Setup / Monitoring / Apex Jobs. They will appear here with a status.