Java

Cum să faci o stivă universală pentru a lucra nu doar cu Integer, ci și cu String și obiecte personalizate?

Ce trebuie avut în vedere atunci când se creează un index pe un tabel mare în producție?

Scrie propria ta clasă care implementează o stivă, cu metodele push, pop și peekMax, care returnează elementul maxim din stivă în O(1).

De ce este nevoie de SELECT FOR UPDATE în loc de synchronized? Și de ce blocarea pesimistă în loc de optimistă?

De ce va apărea o eroare StackOverflowError dacă nu există variabile locale? Cu ce se va umple memoria?

Ce să faci dacă processFile nu poate fi executat după confirmarea tranzacției?

De ce nu se poate folosi pur și simplu o variabilă max în locul celui de-al doilea stivă?

Există un sistem care permite utilizatorilor să lucreze cu fișiere în browser. Tehnologia standard: Java, Spring, React, Postgres. Fișierele sunt stocate în sistemul de fișiere pe backend, metadatele fișierelor în baza de date. Echipa a implementat o funcționalitate: @Transactional public void process(String oldName, String newName) { Long id = exec("select id from file where name='" + oldName + "'"); // executarea unei interogări la baza de date processFile(oldName, newName); // redenumirea fișierului pe disc exec("update file set name='" + newName + "' where id = " + id); // executarea unei interogări la baza de date }

Se poate optimiza stiva în memorie pentru a nu avea o consumare x2?

Ce tip de index să folosiți pentru căutarea în mijlocul sau la sfârșitul unui șir (LIKE '%text%')?

Există un backend, există o interfață de utilizator. Stiva tehnologică este standard: Java, Spring, React, Postgres. Sarcina: Proiectați un endpoint REST care trebuie să preia date din 3 surse și să le returneze către UI, asigurând cea mai mare capacitate posibilă și cel mai mic timp de răspuns posibil (criterii maxime/minime în funcție de condițiile noastre specifice, deoarece în esență nu există o soluție magică și trebuie găsit un compromis). Se știe că vârful RPS așteptat pentru acest endpoint va fi de 200. Detalii cunoscute despre surse: 1. Sursa - baza noastră de date, interogarea durează aproximativ 15 secunde. 2. Sursa - serviciu REST asociat, se degradează până la 2 minute sub 100 RPS, răspunde în 5 secunde în mod normal. Nu putem schimba comportamentul acestei surse. 3. Sursa - serviciu REST asociat, răspunde aleatoriu (nu au fost identificate modele specifice) cu erori 503, în mod normal răspunde în 10 secunde. Nu putem schimba comportamentul acestei surse.

Scrieți o metodă foarte simplă care, la rulare, aruncă o eroare StackOverflowError.