Ygtjki

I have the following code

Map<Account, Integer> accountsMap = new Map<Account, Integer>();
Account a = new Account();
accountsMap.put(a, 1);
a.name='Bob';
//System.debug(accountsMap);
System.debug(accountsMap.get(a));
System.assertEquals(1, accountsMap.get(a));

Debug in the sixth line shows null which is expected and next assert fails. However if I uncomment debug in the fifth line I will get the following log(note that there is no assert failure):

Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?

As noticed in the comments, to reproduce this you have to set the debug level for Apex to anything below FINEST. On FINEST level assert always fails.

Which is a bit unexpected for me as Accounts with different fields should result in a different hash. I know that using sObjects for map keys is bad practice but still interested in how adding a debug statement can change the code behavior?

Map and Set have internal state you cannot directly observe. Internally, they look a bit like this:

class Bucket<U> 
 Integer hashCode;
 U[] values;

public class Map<T, U> 
 List<Bucket<U>> buckets = new List<Bucket<U>>();
 public U put(T key, U value) 
 Integer hashCode = value.hashCode();
 Bucket<U> temp;
 for(Bucket<U> bucket: buckets) 
 if(bucket.hashCode == hashCode) 
 temp = bucket;
 
 
 // hash not found, make new bucket
 if(temp == null) 
 buckets.add(temp = new Bucket<U>());
 temp.hashCode = hashCode;
 
 for(Integer i = 0; i < temp.values.size(); i++) 
 if(temp.values[i].equals(value)) 
 U result = temp.values[i];
 temp.values[i] = value;
 return result; // Returns old value
 
 
 temp.values.add(value); // Adds new value to bucket
 

Of course, this isn't the actual code that happens, just sort of pseudocode. As you can see, a lot of stuff is going on under the covers.

The main point here is that if you change the value, and thus its hashCode, it will no longer be found in its original bucket, which is cached inside the map.

When you force a System.debug, the internal state of the Map is refreshed and buckets are recalculated. This can change the number of keys internally and end up with fewer total elements as well.

This occurs with both Map and Set objects. If you choose to modify the hashCode of a value for a key, you will corrupt the collection's internal state until you debug it, which fixes it.

As you've observed, this causes problems when you insert sObject records, or later modify any of their fields, or otherwise use objects that have unstable hashCode values.

Side note: Using sObject keys is not a Bad Practice™. In fact, I use this technique fairly often. sObject keys allows you to perform certain types of checks efficiently without wrapper classes. However, using this technique means you need to consciously make decisions to avoid corrupting the internal state of the collection.

UPDATE

The below answer is applicable only when the Log Level for Apex is set to FINEST.

The behavior as noted by OP does have an impact if Log Level is set anything below FINEST.

Here's my observation.

If I run the exact code you have where you are adding the Name after adding the object in Map, I never get the debug returning 1.

accountsMap.put(a, 1);
a.name='Bob';

I get it as:

08:57:25:005 USER_DEBUG [5]|DEBUG|Account:Name=Bob=null

Now, this is the expected behavior based on documentation (emphasis mine):

Be cautious when using sObjects as map keys. Key matching for sObjects is based on the comparison of all sObject field values. If one or more field values change after adding an sObject to the map, attempting to retrieve this sObject from the map returns null. This is because the modified sObject isn’t found in the map due to different field values.

Things work as expected if you will have any system.debug or not, only if you have it added as this:

a.name='Bob';
accountsMap.put(a, 1);

As noted in the documentation, exercise caution while using SObjects as keys for maps.

Note that you are using SObject as a key; when used in this way the key evaluation is based on a value comparison, so the state of your SObject is important.

When you insert into the map, the SObject was in one state, but when you get the value you have already changed the state. Whilst what you are seeing seems like strange behaviour, it is (as per @Jayant Das's answer) documented. However, what you are doing is really dodgy (IMHO).

For me, it is a bad idea to use an SObject (or indeed other mutable object) as a key; a map's internal tree/bucket structure depends on the key values and changing the key value under its feet will make the map misbehave. Much as you are seeing.

You would be better off finding a different means to provide a key for the object you are managing in the map. One option is an external ID if you must manage data in the map for SObjects that have no ID (because they are new and not yet inserted). Another is to leverage a combination of other fields within the SObject that provide some unique identity and that do not change. A third option is to hold the SObjects in an array and use the index into that array as the key value.

Whatever you do, the key value for the given SObject should not be allowed to change after first use in the map.