원래 맵에 키가 없으면 원래 키가 있으면 원래 값을 값으로 덮어쓰게 됩니다
map.put(key,value);
이 구현은 원래 값에 1을 추가합니다(이 키가 있다는 전제)
map.put(key,map.get(key)+1);
키에 해당하는 값은 다음과 같이 얻을 수 있습니다. 그렇지 않으면 기본값이 반환될 수 있습니다
map.getOrDefault(key,value);
HashMap에 저장된 일련의 키-값 쌍, 여기서 키는 사용자 정의 유형입니다. HashMap에 넣은 후 외부에서 특정 키의 속성을 변경한 다음 이 키를 사용하여 HashMap에서 요소를 가져옵니다. 이때 HashMap은 무엇을 반환합니까?
저희 사무실 여러 분들의 답변이 일관되지 않습니다. 어떤 사람은 null을 반환한다고 하고, 어떤 사람은 정상적으로 값을 반환할 수 있다고 합니다. 그러나 대답이 무엇이든 확실한 이유는 없습니다. 이 질문이 꽤 흥미롭다고 생각해서 코드 테스트를 작성해봤습니다. 결과는 null입니다. 우리의 사용자 정의 클래스가 hashCode 메서드를 재정의한다는 점에 유의해야 합니다. HashMap이 참조 유형을 저장한다는 것을 알고 있고 외부에서 키를 업데이트했다는 것을 알고 있기 때문에 이 결과는 다소 예상치 못한 결과라고 생각합니다. 이는 HashMap의 키도 업데이트된다는 것을 의미하며, 이는 이 키의 hashCode 반환 값도 발생한다는 것을 의미합니다. . 다양성. 이때 key와 HashMap의 hashCode는 반드시 요소의 hashCode와 동일해야 하며, equals는 동일한 객체이기 때문에 반드시 true를 반환하는데 왜 올바른 값을 반환하지 못하는 걸까요?
여기에는 2가지 케이스가 있습니다. 하나는 Person 클래스이고 다른 하나는 Student 클래스입니다. 위의 관점을 확인해 보겠습니다(결론 포함).
객체 속성을 수정하면 객체 속성이 변경되는지 여부. hashcode => 예
HashMap에 접근할 때 값을 수정하면 속성이 영향을 받나요? => 값이 null입니다
package tech.luxsun.interview.luxinterviewstarter.collection; import lombok.AllArgsConstructor; import lombok.Data; import lombok.NoArgsConstructor; import java.util.HashMap; /** * @author Lux Sun * @date 2021/4/22 */ public class MapDemo0 { public static void main(String[] args) { HashMap<Object, Object> map = new HashMap<>(); // Person Case Person p = new Person("Bob", 12); map.put(p, "person"); System.out.println(p.hashCode()); System.out.println(map.get(p)); p.setAge(13); System.out.println(p.hashCode()); System.out.println(map.get(p)); // Student Case Student stu = new Student("Bob", 12); map.put(stu, "student"); System.out.println(stu.hashCode()); System.out.println(map.get(stu)); stu.setAge(13); System.out.println(stu.hashCode()); System.out.println(map.get(stu)); } } @Data @AllArgsConstructor @NoArgsConstructor class Person { private String name; private Integer age; public int hashCode() { return 123456; } } @Data @AllArgsConstructor @NoArgsConstructor class Student { private String name; private Integer age; }
출력 결과
123456
person
123456
person
71154
Student
71213
null
Source code
hashCode source code
public int hashCode() { int PRIME = true; int result = 1; Object $age = this.getAge(); int result = result * 59 + ($age == null ? 43 : $age.hashCode()); Object $name = this.getName(); result = result * 59 + ($name == null ? 43 : $name.hashCode()); return result; }
map.get source code
/** * Returns the value to which the specified key is mapped, * or {@code null} if this map contains no mapping for the key. * * <p>More formally, if this map contains a mapping from a key * {@code k} to a value {@code v} such that {@code (key==null ? k==null : * key.equals(k))}, then this method returns {@code v}; otherwise * it returns {@code null}. (There can be at most one such mapping.) * * <p>A return value of {@code null} does not <i>necessarily</i> * indicate that the map contains no mapping for the key; it's also * possible that the map explicitly maps the key to {@code null}. * The {@link #containsKey containsKey} operation may be used to * distinguish these two cases. * * @see #put(Object, Object) */ public V get(Object key) { Node<K,V> e; return (e = getNode(hash(key), key)) == null ? null : e.value; } /** * Computes key.hashCode() and spreads (XORs) higher bits of hash * to lower. Because the table uses power-of-two masking, sets of * hashes that vary only in bits above the current mask will * always collide. (Among known examples are sets of Float keys * holding consecutive whole numbers in small tables.) So we * apply a transform that spreads the impact of higher bits * downward. There is a tradeoff between speed, utility, and * quality of bit-spreading. Because many common sets of hashes * are already reasonably distributed (so don't benefit from * spreading), and because we use trees to handle large sets of * collisions in bins, we just XOR some shifted bits in the * cheapest possible way to reduce systematic lossage, as well as * to incorporate impact of the highest bits that would otherwise * never be used in index calculations because of table bounds. */ static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16); } /** * Implements Map.get and related methods * * @param hash hash for key * @param key the key * @return the node, or null if none */ final Node<K,V> getNode(int hash, Object key) { Node<K,V>[] tab; Node<K,V> first, e; int n; K k; if ((tab = table) != null && (n = tab.length) > 0 && (first = tab[(n - 1) & hash]) != null) { if (first.hash == hash && // always check first node ((k = first.key) == key || (key != null && key.equals(k)))) return first; if ((e = first.next) != null) { if (first instanceof TreeNode) return ((TreeNode<K,V>)first).getTreeNode(hash, key); do { if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) return e; } while ((e = e.next) != null); } } return null; }
테이블이 먼저 얻어지는 것을 볼 수 있는데, 실제로는 배열입니다. 그런 다음 테이블에서 키에 해당하는 값을 찾습니다. 찾는 기준은 해시가 전달된 매개변수의 해시와 동일하고 다른 두 조건 중 하나를 충족하는 것입니다: k = e.key, 이는 동일한 객체이거나 동일한 대상의 키임을 의미합니다. 전달된 키의 우리의 문제는 hash(key.hashCode())에 있습니다. 요소를 저장할 때 HashMap이 키의 hashCode를 해시하는 것을 볼 수 있습니다. 획득된 해시는 결국 요소 저장 위치의 기초로 사용됩니다. 우리 상황에 맞춰 처음으로 저장할 때 해시 함수는 key.hashCode를 매개변수로 사용하여 값을 가져온 다음 이 값을 기반으로 특정 위치에 요소를 저장합니다.
요소를 다시 가져오면 key.hashCode의 값이 변경되었으므로 여기의 해시 함수 결과도 변경되었으므로 이 키의 저장 위치를 가져오려고 하면 올바른 값을 가져올 수 없습니다. 결국 대상 요소를 찾을 수 없습니다. 이를 올바르게 반환하는 것은 매우 간단합니다. 해당 hashCode가 수정하려는 속성에 의존하지 않도록 Person 클래스의 hashCode 메서드를 변경합니다. 그러나 실제 개발에서는 이 작업을 수행해서는 안 됩니다. 두 객체의 속성이 다르므로, 정확히 동일한 경우 서로 다른 hashCode 값이 반환될 수 있습니다.
결론은 HashMap에 객체를 배치한 후 속성 제한이 적용되지 않는 엔터티 클래스의 hashCode 메서드를 재정의하지 않는 한 키의 속성을 수정하지 않는다는 것입니다.
위 내용은 Java의 키 값을 기반으로 Hashmap의 값을 수정하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!